mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega88 - Reset nach Burst


Autor: Frank S. (frassch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: frassch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: frassch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SeppK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du bitte mal dein Leiterplatten-Layout posten.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: frassch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: frassch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.