Hallo, mir steigt ein ATmega88 bei Bursteinfluss (Einkopplung auf die Zuführungskabel der Schaltung) aus, d.h. startet die Programmabarbeitung von neuem. Um den den Einfluss des analogen Schaltungsteils auszuschließen, habe ich testeise alle für die Applikation genutzten DIO's auf definierten H bzw. L Pegel gesetzt. Außerden laufen zwei Testroutinen, eine zur Anzeige des Programmstarts und eine zur Anzeige der Resetquelle bei Programmstart (Abfrage MCUSR auf PORF, EXTRF, WDRF, BORF). Bei Bursteinfluss resettet der Controller, ohne dass eine der vier Resetquellen dafür in Frage kommt (... jedenfalls scheinen die entsprechenden Bits nicht gesetzt zu sein). Hier noch einige Randbedingungen zur Controllerbeschaltung: - VCC mit L-C Filterbeschaltung + Varistor - AVCC mit L-C Filterbeschaltung - Reset Pin mit Pullup + Diode gegen VCC, Kondensator gegen GND - externer Quarz mit 20 MHz - alle nicht genutzten DIO's sind mit einem Pulldown + Parallel- kondensator beschaltet und als Ausgang Low konfiguriert (DDxn = 1, PORTxn = 0, PUD = X) Außerdem sind alle Schaltungzuführungen + Schaltungs-Spannungsversorgung mit EMV-Beschaltung versehen. Natürlich hat auch die Layoutgestaltung einen wesentlichen Einfluss auf das EMV-Verhalten, mich interessiert daher durch welche Konstellationen/Einflüsse der Controller zum resetten gebracht werden kann bzw. Gegenmaßnahmen. Wie aussagekräftig ist die Abfrage der Resetquellen (MCUSR)? Hat jemand schon Erfahrungen mit der EMV-Festigkeit des ATmega88 gesammelt? (... es soll ja Controller geben die von Haus aus nicht gehen ...) Gruss frassch
Frank S. wrote: > Bei Bursteinfluss resettet der Controller, ohne dass eine der vier > Resetquellen dafür in Frage kommt (... jedenfalls scheinen die > entsprechenden Bits nicht gesetzt zu sein). Dann läuft Dein Programm in den Wald, d.h. es ist ein Softwarefehler. Es wird an den Eingängen ein unerwarteter Zustand auftreten oder ein Interrupt wird zu oft getriggert oder Du hast nen Interrupt ohne Handler enabled usw. Peter P.S.: Unbedingt Bronwout-Reset enablen!
Kannst du mit einem Oszi diese Burst auf den verschiedenen Leitungen erkennen? Fange bei der Stromversorgung vor dem Spannungsregler an, könnte sein das die hier ein LC Filter eher angebracht ist als am µC. Könntest auch den Elko vor dem Spannungsregler mit einer Diode gegen Endladen schützen also falls dein Verbraucher auch die Stromversorgung vor dem Spannungsregler impulsartig belastet und dieser dann vielleicht kurz in die Knie geht, was du mit dem Multimeter garnicht erkennst. Ansonsten das Programm mal durchsimulieren. Könnte mir vorstellen das ein Interrupt aufgerufen wird den du garnicht verwenden wolltest und wenn dann kein reti in der Interrupttabelle steht, macht das Programm genau dort weiter anstatt wieder dort zurückzuspringen wo es war bevor der Interrupt aufgetreten ist.
Danke @Peter > Dann läuft Dein Programm in den Wald, d.h. es ist ein Softwarefehler. - ich habe die Anzeige der Resetquellen ohne Bursteinfluss getestet, ... das hat tadellos funktioniert > Es wird an den Eingängen ein unerwarteter Zustand auftreten oder ein > Interrupt wird zu oft getriggert oder Du hast nen Interrupt ohne Handler > enabled usw. - zum Testen habe ich alle genutzten Eingänge auf definierten H bzw. L Pegel gesetzt. An Hardware nutze ich nur die drei Timer mit CTC Match ISR, sonst sind keine weiteren Interrups enabled ( ... überprüfe ich sicherheitshalber aber noch mal ...) > Unbedingt Bronwout-Reset enablen! - Bronwout-Reset(4.3V) + Watchdog-Reset ist enabled Ohne Bursteinfluss läuft meine Anwendung einwandfrei. Der Burst lässt mir jedoch die Schaltausgänge flattern, welche vom Controller angesteuert werden. Zum Testen habe ich auch schon eine Minimalsoftware probiert, übertragen etwa so: int main(void) { - initialisiere Ports // keine weitere Hardware genutzt bzw. enabled - initialisiere Watchdog - checke und signalisiere Resetsource - signalisiere Programmstart while(1) { - setze stur die Schaltausgänge // unabhängig von irgendwelchen - reset Watchdog // Eingängen } } Im laufenden Betrieb und bei Bursteinfluss wird der erneute Programmstart aber keine der 4 Resetquellen (PORF, EXTRF, WDRF, BORF) signalisiert. Man merkt es auch am flattern der Schaltausgänge - der Burst bringt den Controller zum Neustart.
Welches Bauteil erzeugt deine Burst kannst du diese nicht direkt an der Quelle unterdrücken? Hast du ein Oszilloskop zur Verfügung? Eingänge kannst du intern eigentlich nur auf definiert High legen also Pullups aktivieren ansonsten hängen diese in der Luft. Vieleicht bringt ein externer Pullup mit einem geringeren Wert mehr.
Hallo @Kosmos Also meine schaltung muss einen extern auf die Zuleitungen eingekoppelten Burst abkönnen. Oszillographiert habe ich während der Bursteinkopplung schon ausgiebig. Ist aber nur eingeschränkt möglich, weil mann in der "burstverseuchten Umgebung" mit der Oszispitze wiederum auf die Schaltung einkoppelt bzw. die Messung verfälscht. Ein Oszi mit optischer Trennung habe ich nicht zur Verfügung. Natürlich sind Burstnadeln (im ns-Bereich) z.B auf VCC oder RESET zu erkennen, ich halte das aber für wenig aussagekräftig. Was mich stresst, ist die Tatsache, dass wenn durch Bursteinfluss z.B. VCC einknickt entweder BORF oder PORF gesetzt sein müsste (... denke ich jedenfalls ... ) und man so die Ursache des Programmneustartes hätte. So aber habe ich keinen Ansatzpunkt warum der Controller resettet (... und das tut er ...). Wie gesagt die Layoutgestaltung hat wesetlichen Einfluss auf das EMV-Verhalten, daher die Frage ob irgendjemand schon ähnliche Erfahrungen hatte? Gruss frassch P.S.: - das mit den Pullups probiere ich auf jeden Fall aus
ich nehme mal an du musst diese Burst Test für irgendeine Zulassung durchführen. Wie sind denn diese vorgeschriebenen Bursts also Impulslänge und Impulshöhe? Könnte mir vorstellen das deine Entstörmaßnahmen nicht nah genug am µC sind und vielleicht auch nicht vollständig.
Hallo @SeppK & @kosmos An den Layoutausdruck komme ich vor Dienstag nicht ran. Die Bursts werden mit 2.1 KV bei 15 ms Impulsdauer (Puls/Pausenverhältnis ca. 500us) auf die Leitungen eingekoppelt. Ich habe mich auch bemüht Entstörmaßnamen so nah als möglich am Controller anzuordnen. Den Atmega88 setze ich aus Platzgründen zum ersten Mal ein, habe also noch keine Erfahrungen mit diesem Typ. Das das Layout bzw. unvollständige Entstörmaßnahmen als Fehlerquellen in Frage kommen ist mir klar. Jedoch scheue ich den Aufwand z.B. einer Layoutänderung von derzeit 2-lagig auf beispielsweise 4-lagig (mit durchgehenden GND- ,VCC-Layer usw. ...) ohne vorher das Netz abgeklopft zu haben. Ich gehe mal davon aus, dass man von Atmel kein Feedback bekommt wenn evtl. solche Probleme mit dem Controllertyp bekannt sind. Das mit dem "undefinierten" Reset will mir einfach nicht in den Kopf.
frassch wrote: > Im laufenden Betrieb und bei Bursteinfluss wird der erneute > Programmstart > aber keine der 4 Resetquellen (PORF, EXTRF, WDRF, BORF) signalisiert. Dann prüfe erstmal, ob diese Anzeigeroutine auch funktioniert, indem Du alle Resetquellen (extern, watchdog, Unterspannung, Einschalten) mal absichtlich triggerst. Gib auch mal den SP aus, der muß ja nach einem echten Reset auf RAMEND zeigen (d.h. nach dem Call des Main auf RAMEND-2). Unter C muß man dazu den Init-Code patchen (z.B. im Hexfile das SP laden durch NOP ersetzen). Und setze ihn dann im Main auf RAMEND-4, damit er bei Programmabsturz garantiert nicht auf RAMEND steht. Verbinde mal den Resetpin direkt mit VCC. Wenn längere Leitungen direkt zum MC gehen, dann schalte mal unmittelbar am MC 100 Ohm in Reihe. Peter
Schreib doch mal ein einfaches Programm wo sich der µC nicht verlaufen kann. Also für jeden Interruptaufruf eine andere LED leuchten lassen, eine bestimmte Zahl austakten oder an LED Array ausgeben damit du es visualisieren kannst in welche Routine der µC gesprungen ist. Ein Überspannungsproblem hätte dir ja den entsprechenden Pin schon gegrillt. Und eine einkopplung auf einen Pin würde wegen des Pullups eher auschließen. Wie schaut deine Schutzmaßnahme an den Pins aus wo der Burst draufgelassen wird?
Hallo @Peter & kosmos > Dann prüfe erstmal, ob diese Anzeigeroutine auch funktioniert, indem Du > alle Resetquellen (extern, watchdog, Unterspannung, Einschalten) mal > absichtlich triggerst. - habe ich gemacht - funktioniert einwandfrei ... > Gib auch mal den SP aus, der muß ja nach einem echten Reset auf RAMEND > zeigen (d.h. nach dem Call des Main auf RAMEND-2). - guter Tipp, werde ich testen ... > Schreib doch mal ein einfaches Programm wo sich der µC nicht verlaufen > kann. Also für jeden Interruptaufruf eine andere LED leuchten lassen, > eine bestimmte Zahl austakten oder an LED Array ausgeben damit du es > visualisieren kannst in welche Routine der µC gesprungen ist. - denke das habe ich mit dem oberhalb geposteten Code schon getan, ohne dass Interrupts aktiv waren. > Wie schaut deine Schutzmaßnahme an den Pins aus wo der Burst > draufgelassen wird? - Der Burst wird auf die Zu- und Schaltausgangsleitungen der kompletten Schaltung eingekoppelt, es ist für mich momentan nicht feststellbar an welcen µC-Pin sich das auswirkt, deshalb der Aufwand mit der Resetquellenabfrage. Da fällt mir ein, dass ich den Controller auch schon mit deaktiviertem Bronwout-Reset, Watchdog-Reset und externen Reset getestet habe - mit dem gleichem Ergebnis ...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.