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
Ja, das klingt irgendwie nach einmal zu viel getoggelt...
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.
:
Bearbeitet durch User
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.
> Taktversorgung ist ein Oszillator
Was sonst? Einen Dirigenten hätte ich auch nicht erwartet :-)
SCNR
Stefan U. schrieb: > Was sonst? Einen Dirigenten hätte ich auch nicht erwartet :-) Ein Mikronom (Metronom mit Microschalter)!
> 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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.