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
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?
> 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
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.
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
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.
> 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
1
#define _QMATRIX_
2
#define __ATmega164PA__
3
#ifndef QT_DELAY_CYCLES
4
#define QT_DELAY_CYCLES 10
5
#endif
6
7
#define QT_MAX_NUM_ROTORS_SLIDERS 2
8
#define _ROTOR_SLIDER_
9
10
#define QT_NUM_CHANNELS 16
11
12
#define NUM_X_LINES 8
13
14
#define NUM_X_PORTS 1
15
16
#define PORT_X_1 D
17
18
#define NUM_Y_LINES 1
19
20
#define PORT_YA A
21
#define PORT_YB A
22
23
#define PORT_SMP A
24
#define SMP_PIN 5
25
26
// Kommentarloses "Please do not edit", ok.
27
#define PORT_NUM_1 1
28
29
#define TICKS_PER_MS 16u
30
31
#define QT_TIMER_PERIOD_MSEC 1u
32
33
#define QT_MEASUREMENT_PERIOD_MS 15u // Touch Measure alle 10ms
Im Hauptprogramm wird die Library dann initialisiert und periodisch
aufgerufen.
1
touch_init();
2
for(;;)
3
{
4
DDRD|=0xFF;// QTouch-Port auf Ausgang
5
PORTD=0x00;// QTouch-Port auf LOW
6
// touch_init_ports();
7
touch_measure();
8
// Lies die Sliderdaten und gib sie direkt weiter.
9
sliderpos=GET_ROTOR_SLIDER_POSITION(0);
10
slideronoff=GET_SENSOR_STATE(0);
11
TWIEval();// Wertet aus, ob Daten über I2C angekommen sind.
12
TWIButtonMux();// Fragt die Taster und den Slider ab und legt die neuen Werte in den I2C Sendepuffer.
13
14
if(sanity1==sanity2)// Sind beide 13 und sollten sich nie verändern
15
{
16
wdt_reset();
17
}
18
else// Falls doch, Watchdog Timeout lassen.
19
{
20
while(1)
21
{
22
;
23
}
24
}
25
}
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.
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.
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
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.
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
doof_1.jpg
(260 KB)
doof_2.jpg
(180 KB)
