LatchUp (?) nach ESD-Beschuss im ATmega

[Christian W. (christian_w79)]

Hallo,

die Ausgänge meines ATmega verpolen sich, wenn ich mit eine 4kV 
Direktentladung auf das Metallgehäuse mache. Aber von vorne.

Ich sende über 8 Ports eines ATmega Impulse in meinen langen QMatrix 
Slider, der aus 8 Segmenten besteht (X-Lines). Diese gehen in eine 
Y-Line, die wiederum vom ATmega eingelesen wird.

Nach dem ESD-Beschuss passiert es manchmal, dass einer oder zwei dieser 
8 Ports die Bursts nicht von unten nach oben burstet (also von 0V nach 
3,3V) sondern von oben nach unten (von 3,3V nach 0V). Dadurch sind meine 
eingelesenen Resultate für die Katz, der Slider "funktioniert nicht 
mehr". Der Rest des ATmega läuft problemlos weiter: LED-Multiplexing 
funktioniert, I2C geht, Tastendrücke werden erkannt. Ich kriege diesen 
Zustand durch einen HW-RESET des betroffenen ATmegas weg.

Ist das ein LatchUp? Was kann ich dagegen tun?

Ich habe bereits 1k1 Serien-R in allen Leitungen, die habe ich auf 4k7 
erhöht und weiterhin gegen Ferritperlen getauscht. Nichts hat dieses 
Problem verbessert. Der ATmega ist mit 100nF und 1uF an zwei von drei 
PowerPins abgeblockt. ESD-Puls ist 4kV Kontakentladung auf das 
Metallgehäuse. Dieses Metallgehäuse liegt, nur durch eine Isolierfolie 
getrennt, direkt auf der PCB auf.

Schönen Gruß,
Christian

[Peter D. (peda)]

Sinnvoll wäre, erstmal den AVR-Typ anzugeben.

Der Effekt klingt sehr nach Softwarefehler, d.h. irgendwas in Deinem 
Programm fängt von Dir unvorhergesehene Eingangssignale nicht richtig 
ab.

Die BOR-Fuses hast Du doch gesetzt und auch die WDTON-Fuse, sowie den 
Quarz im Full-Swing Mode?

[Christian W. (christian_w79)]

> Sinnvoll wäre, erstmal den AVR-Typ anzugeben.

Es ist ein ATmega164PA.

> Die BOR-Fuses hast Du doch gesetzt und auch die WDTON-Fuse, sowie den
> Quarz im Full-Swing Mode?

BOR ist auf 2,7V bei einer Betriebsspannung von 3,3V. Taktversorgung ist 
ein Oszillator, die Fuses stehen auf "externer Takt" mit einer 
StartUp-Zeit von +0ms. Der WatchDog steht auf 1s und ist per Fuses 
eingeschaltet.

> Der Effekt klingt sehr nach Softwarefehler, d.h. irgendwas in Deinem
> Programm fängt von Dir unvorhergesehene Eingangssignale nicht richtig
> ab.

Ok. Ich halte das mal im Hinterkopf. Ich nutze die Atmel QTouch Library. 
Die übernimmt periodisch das konfigurieren der Ausgangsports, fragt die 
Touch-Sensoren ab und gibt die Ausgangsports wieder frei. Wenn, dann 
müsste an dieser Stelle etwas schief gehen.

Christian

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Ja, das klingt irgendwie nach einmal zu viel getoggelt...

[Mark S. (voltwide)]

Wenn die Platine direkt über dem Metall liegt, hast Du vmtl ein echtes 
Hardwareproblem - die Einkopplung erfolgt dann höchstwahrscheinlich 
magnetisch.
Mein tip wäre - alles so klein und eng wie möglich aufzubauen (SMD0402) 
und Leiterschleifen zu minimieren.

Vor Jahren hatte ich ein ganz ähnliches Problem: Mikrokontroller in eng 
anliegendem Metallgehäuse. Testweise wurde der Microcontroller komplett 
auf Ferritperlen "aufgebockt". Auch das hatte nichts genützt - die Ports 
kamen bei ESD-Beschuss durcheinander.
Allerdings ließ sich zeigen, das der ProzessorKern nicht abstürzte,
sondern nur die außen liegenden port-Register ihre Inhalte verloren.
Letztendlich führte also eine Softwarelösung zum Ziel: Sämtliche ports 
wurden periodisch neu initialisiert.

btw - von latchup spricht man erst, wenn der ESD-Impuls einen internen 
parasitären Thyristor zündet, dieser die Betriebsspannung kurzschließt, 
und daraufhin der chip aufbrennt.

[Christian W. (christian_w79)]

Hallo Mark,

> Wenn die Platine direkt über dem Metall liegt, hast Du vmtl ein echtes
> Hardwareproblem - die Einkopplung erfolgt dann höchstwahrscheinlich
> magnetisch.
> Mein tip wäre - alles so klein und eng wie möglich aufzubauen (SMD0402)
> und Leiterschleifen zu minimieren.

Vielen Dank für dein Posting. Ich glaube Du hast recht. Ich habe das 
schon länger vermutet, wusste aber nicht, ob meine Formulierung des 
Problems plausibel ist. Kleiner aufbauen kann ich nicht: Der Fader ist 
lang (20cm) und irgendwo müssen die Leitungen hin. Ich werde sehen, ob 
ich den Abstand zwischen PCB und Metall vergrößern kann.

> Vor Jahren hatte ich ein ganz ähnliches Problem: Mikrokontroller in eng
> anliegendem Metallgehäuse. Testweise wurde der Microcontroller komplett
> auf Ferritperlen "aufgebockt". Auch das hatte nichts genützt - die Ports
> kamen bei ESD-Beschuss durcheinander.
> Allerdings ließ sich zeigen, das der ProzessorKern nicht abstürzte,
> sondern nur die außen liegenden port-Register ihre Inhalte verloren.
> Letztendlich führte also eine Softwarelösung zum Ziel: Sämtliche ports
> wurden periodisch neu initialisiert.

Ferritperlen und Varistoren haben haben bei mir bisher nur homöopathisch 
geholfen. Auch den "Reset, ohne Reset zu machen" kenne ich: Bei mir 
reagieren manchmal Hardwareteile nicht mehr (LEDs, I2C), während der 
Rest des Controllers weiter läuft. Trotz eines eingeschalteten Watchdogs 
wird dieser aber definitiv nicht angesprungen. Es ist wie als wenn Werte 
im RAM gelöscht oder verändert werden.

Ich werde jetzt versuchen, ob die Atmel Library die Teil-Initialisierung 
der Ports erlaubt. Falls nicht werde ich bei jedem Durchlauf die Ports 
auf plausible Werte initialisieren, bis es passt.

Christian

[Jim M. (turboj)]

Mark S. schrieb:
> Wenn die Platine direkt über dem Metall liegt, hast Du vmtl ein echtes
> Hardwareproblem - die Einkopplung erfolgt dann höchstwahrscheinlich
> magnetisch.

Unwahscheinlich. Denn bei echten Hardware Problemen wäre da nicht nur 
die Polarität vertauscht.

Ich würde hier eher ein Softwareproblem sehen, beispielsweise durch 
Read-Modify-Write und Interrupts. Der OP sollte mal seinen Source Code 
als Anhang posten.

[Stefan F. (Gast)]

> Taktversorgung ist ein Oszillator

Was sonst? Einen Dirigenten hätte ich auch nicht erwartet :-)

SCNR

[Marc H. (marchorby)]

Mach mal ein Foto vom Aufbau!

[PaulBaumannReplacement (Gast)]

Stefan U. schrieb:
> Was sonst? Einen Dirigenten hätte ich auch nicht erwartet :-)

Ein Mikronom (Metronom mit Microschalter)!

[Christian W. (christian_w79)]

> Unwahscheinlich. Denn bei echten Hardware Problemen wäre da nicht nur
> die Polarität vertauscht.

Aus der Menge der Fehlfunktionen ist das der schlimmste Fehler, da er 
zum C beim ESD-Test führt. Die anderen führen hauptsächlich zum Reset 
des Atmels und das kann ich mit dem Watchdog gut auf ein B drücken.

Welcher Teil des Source Codes ist denn interessant? Ich nutze die Atmel 
Library. Die wird im File touch.h parametriert

#define _QMATRIX_
#define __ATmega164PA__
#ifndef QT_DELAY_CYCLES
     #define QT_DELAY_CYCLES 10
#endif

#define QT_MAX_NUM_ROTORS_SLIDERS 2
#define _ROTOR_SLIDER_ 

#define QT_NUM_CHANNELS   16

#define NUM_X_LINES  8

#define NUM_X_PORTS  1

#define PORT_X_1  D

#define NUM_Y_LINES  1

#define PORT_YA   A
#define PORT_YB   A

#define PORT_SMP   A
#define SMP_PIN   5

// Kommentarloses "Please do not edit", ok.
#define PORT_NUM_1  1

#define TICKS_PER_MS 16u

#define QT_TIMER_PERIOD_MSEC  1u

#define QT_MEASUREMENT_PERIOD_MS 15u  // Touch Measure alle 10ms

Im Hauptprogramm wird die Library dann initialisiert und periodisch 
aufgerufen.

touch_init();
for( ; ; )
{  
    DDRD |= 0xFF; // QTouch-Port auf Ausgang
    PORTD = 0x00; // QTouch-Port auf LOW
    // touch_init_ports();
    touch_measure();
    // Lies die Sliderdaten und gib sie direkt weiter.
    sliderpos = GET_ROTOR_SLIDER_POSITION(0);
    slideronoff = GET_SENSOR_STATE(0);
    TWIEval();  // Wertet aus, ob Daten über I2C angekommen sind.
    TWIButtonMux();  // Fragt die Taster und den Slider ab und legt die neuen Werte in den I2C Sendepuffer.

    if(sanity1 == sanity2) // Sind beide 13 und sollten sich nie verändern
    {
      wdt_reset();
    }
    else // Falls doch, Watchdog Timeout lassen.
    {
      while(1)
      {
        ;
      }
    }
  }

Das Setzen des QTouch-Ports auf Ausgang und LOW hat nichts gebracht. Der 
Fehler besteht weiterhin.

Der Atmel Support schrieb mir: Erhöhen Sie die Längs-R bis 100kOhm und 
ggf. auch bis 1MOhm. Passen Sie entsprechend die Burst Länge an. Lesen 
Sie das hier durch: 
http://ww1.microchip.com/downloads/en/AppNotes/doc8425.pdf

Ich bin bei 20k und es ist noch nicht besser geworden.

[Peter D. (peda)]

Christian W. schrieb:
> TWIEval();

Was gerne abstürzen kann, ist das HW-TWI. Das HW-TWI der AVRs ist leider 
sehr empfindlich gegen Störungen auf SDA/SCL. Sobald es sich verklemmt 
hat, muß man es disablen und händisch rücksetzen (9 SCK-Takte mit <= 
100kHz).
Oder man erspart sich den ganzen Hassle und macht es komplett per 
Bit-Banging, als Single-Master kein Problem.

Kannst ja mal zum Test ein paar Masseschlüsse auf SDA/SCL mit ner 
Tastspitze machen. Dann stürzt es auch ganz ohne EME ab. Es muß 
natürlich gerade ein I2C-Transfer laufen.

[Heiner (Gast)]

Peter D. schrieb:
> Oder man erspart sich den ganzen Hassle und macht es komplett per
> Bit-Banging, als Single-Master kein Problem.

so löst Herr Sonnenschein die Probleme. Wenns nicht geht, einfach
was anderes zusammen pfuschen, damit das schlechte Layout nicht 
auffällt.

Bitte nicht nachmachen.

lg Heiner

[Franz (Gast)]

Peter D. schrieb:
> Sobald es sich verklemmt
> hat, muß man es disablen und händisch rücksetzen (9 SCK-Takte mit <=
> 100kHz).

Kannst du das Phänomen und die Lösung bitte noch etwas genauer 
beschreiben? Was heißt denn in diesem Zusammenhang "verklemmt"? Ich 
benutze den I2C in den AVRs schon viele Jahre, habe das aber noch nie 
beobachtet, obwohl ich teilweise sogar echt pfuschig einfach mal 
meterweise Flachbandkabel mit I2C-Signal verlegt habe.....

Wie äußert sich das Ganze? Ist dein AVR Master oder Slave? Wartet der 
endlos auf ein Signal? Stop, Ack oder Nack? Ich habe da z.B. Timeouts 
drin. Vielleicht beobachte ich deswegen keine Probleme.

[Christian W. (christian_w79)]

Ich wollt's mal auflösen. Das Grüne ist die PCB.

Das Alugehäuse hat Aussparungen für ein Display. Die dünnen Stege am 
Rand haben nicht dafür ausgereicht, die Energie, die durch die 
4kV-Entladung eingespeist wird, ausreichend schnell abzuführen.

Die Energie des Impulses möchte so schnell wie möglich zu der Stelle 
"SHIELD RJ45 PoE". Dort ist der SHIELD des Netzwerkkabels aufgelegt, 
über dessen PoE das System mit Energie versorgt wird. Ich vermute, dass 
die sich ausbreitende Welle (?) an den schmalen Stegen reflektiert wird 
und den darunter liegenden ATmega stört.

Nachdem ich den Displayausschnitt auf der Rückseite großflächig mit 
Kupferband überbrückt habe ist überhaupt nichts mehr abgestürzt. Mein 
ATmega hat sich nicht mehr RESETed, der Verpolungsfehler ist nicht mehr 
aufgetreten. Auch der Fall, wo nicht die gewünschte Anzahl an Bursts 
gesendet wurde ist nicht aufgetreten (der ATmega sendete bspw. einen 
Burst wo er 128 hätte senden sollen.)

Christian