Hallo zusammen,
ich muss zu meiner Schande gestehen, dass ich bezüglich µController noch
wenig Erfahrung habe. Da ich aber zur Zeit ein Projekt bearbeite, bei
dem ich Probleme mit dem ATmega8 habe, wende ich mich an Euch Experten
mit folgender Frage:
Die Tests die ich gerade durchführe sind sogenannte Burst Tests. Leider
lässt sich der ATmega durch diese derartig stören, dass nicht einmal
mehr die Watchdog mehr greift. Dazu sei gesagt, das ein Burst den
Controller sowohl "stoppen" kann, er also nichts mehr macht, als auch
ihn wieder zum "leben" zu erwecken, so dass alles wieder einwandfrei
funktioniert!
Hat jemand Rat was man hierbei machen kann oder was für einen Controller
man einsetzen sollte?
Danke und Gruß
Olaf
Du verwechselst wohl Watchdog mit David Copperfield?
Nein, ein Watchdog kann nicht zaubern!
Du mußt schon alle ESD-Maßnahemn treffen, z.B. Abblocken der VCC, aller
Ein- und Ausgänge, Beschalten alle unbenutzten Portpins, Einschalten
Brownoutreset.
Und vor allem den Watchdog nur an einer Stelle triggern, wo das Programm
nur bei einwandfreier Funktion vorbeikommt.
Ein Timerinterrupt ist dagegen ideal, um einen Watchdog völlig nutzlos
zu machen, da er noch lange gehen kann, wenn das Mainprogramm schon
längst abgestürzt ist.
Peter
@ The Devil:
das sind HardwareTests und keine Softwaretests.
@ Peter:
sorry, ich vergass zu erwähnen, dass sämtliche, auch von Dir
aufgeführten EMV-Massnahmen getroffen wurden.
Ich verstehe jedoch nicht die Sache mit dem Timerinterrupt? Da der
Watchdog zyklisch am Ende des Mainprogramms zurückgesetzt wird, kann
doch ein Timerinterrupt oder ein nicht ablaufendes Programm den
Watschdog nicht lahmlegen?
Ganz im Gegenteil, hier müsste doch der Watchdog gerade zuschlagen (weil
er nicht zurückgesetzt wird, dieser läuft nach meinem Wissensstand als
eigenständige Hardwareeinheit in dem verwendeten µController) oder
nicht?
Gruß
Olaf
Olaf P. wrote:
> Ich verstehe jedoch nicht die Sache mit dem Timerinterrupt?
Das Hauptproblem dürfte sein, dass du zuwenig Informationen
rausrückst um irgendetwas Sinnvolles sagen zu können. Daher
sind alle auf Raten angewiesen und kramen die häufigsten
Ursachen hervor.
Ein beliebter Fehler ist es, den Watchdog in einem Timer
interrupt zurückzusetzen, was natürlich den Sinn eines
Watchdog komplett ad absurdum führt.
Bis jetzt ist dein Frage in die Kategorie:
"Mein Auto geht nicht, obwohl ich die Sonnenblende runtergeklappt
habe" einzuordnen.
Hallo,
also was meine Unwissenheit angeht, dazu habe ich bereits am Anfang
etwas geschrieben und tut mir leid, das ich da Newbee bin. Alles was
sich daraus an Informationsübertragung ergibt, ist entsprechend
schlecht. Auch hierfür ein Sorry, ist keine Absicht.
Alles was ich über den Watchdog weis, ist das dieser unabhängig vom
Prozessortakt arbeitet und auch eine eigene Hardware darstellt, obgleich
er im Controller implementiert ist. Es ist wohl ein Counter, der wenn er
nicht zurückgesetzt wird einen Reset durchführt. Im Mainprogramm wird
dieser Reset (und er wird auch nur da durchgeführt, nicht etwa über
Fuses bereits voreingestellt) am Ende des Programms aufgerufen. Entferne
ich den Resetbefehl, führt der Watchdog den Reset ordnungsgemäß durch.
Im Normalbetrieb (ohne Burst Test, diese dienen dafür, wie sich Geräte
bei Netzstörungen verhalten) funktioniert alles einwandfrei.
Bei einem Burst kann (muss nicht) der Prozessor irgendwo hängen
bleiben(wird also gestört) und kann demnach auch den watchdog nicht
zurücksetzen. Dieser aber schlägt in dem Fall ebensowenig zu und
resetted den Controller nicht.
Ein weiterer Burst kann (ist aber auch nicht zwingend) den Controller
wieder zum Normalbetrieb zurückholen!
Vielleicht gibt es hierzu ja erkenntnisse, die sich Berücksichtigen
liessen, aber dafür kenne ich mich absolut nicht aus!
Grüße
Olaf
Olaf P. wrote:
> Bei einem Burst kann (muss nicht) der Prozessor irgendwo hängen> bleiben(wird also gestört) und kann demnach auch den watchdog nicht> zurücksetzen. Dieser aber schlägt in dem Fall ebensowenig zu und> resetted den Controller nicht.
Du mußt erstmal prüfen, ob diese Vermutung stimmt.
Es kann ja durchaus sein, daß das Programm nichts sinnvolles tut, aber
trotzdem den Watchdogresetbefehl durchläuft.
Toggle mal nen IO-Pin (LED) dabei, dann kannst Du sehen, ob sie pulst.
Setze auch mal die Watchdogfuse, damit er nicht versehentlich disabled
wird.
Versuche mal nach jedem Reset auszugeben, was die Resetquelle war.
Wenn er hängt, prüfe, ob er durch einen externen Reset (nicht power on
reset) wieder weiter läuft.
Peter
Olaf P. wrote:
> nicht zurückgesetzt wird einen Reset durchführt. Im Mainprogramm wird> dieser Reset (und er wird auch nur da durchgeführt, nicht etwa über> Fuses bereits voreingestellt) am Ende des Programms aufgerufen. Entferne> ich den Resetbefehl, führt der Watchdog den Reset ordnungsgemäß durch.
Ich kann dieser Beschreibung nicht recht folgen. Kann es sein, dass wir
über Sinn und Unsinn eines Watchdogs unterschiedlicher Ansicht sind? Ein
Watchdog ist dazu da, im Regelfall nicht aktiv zu werden. Er wird im
Hautpprogramm immer mal wieder daran erinnert, dass alles noch lebt und
führt folglich nicht zum Reset. Nur wenn das Programm dieser
Errinnerungen lange genug unterlässt, gibt's einen Reset.
In derart kritischer Umgebung ist auch anzuraten, den Watchdog bereits
per Fuse zu freizuschalten. Denn sonst entsteht ein Fenster zwischen per
Watchdog ausgelöstem Reset und erneuter Freischaltung im Programm, in
dem Hänger einfach bloss zum Aufhängen führen.
PS: Kann auch sein, das ich sprachlich etwas verwirrt bin.
Watchdog-Reset kann zweiterlei bedeuten. Einerseits den Reset vom
Watchdog-Timer, andererseits den vom Watchdog ausgelösten Reset. Was
ungefähr das Gegenteil davon ist.
Hallo,
je nach Taktung kann so nen mega8 schon mal bei einer ordentlichen
Störung hängenbleiben (selbst schon mal unfreiwillig ausprobierten
müssen). Der Fehler geht meistens Vom Taktgenerator aus, d.h. der
Oszillator hört auf. Um die Sache um einiges Stabiler zu machen würde
ich die CKOPT-Fuse programmieren (heißt in einigen Proggersoftware auch
"Full Amplitude") damit schwingt der Oszillator mit vollem Hub und ist
somit um einiges Stabiler. Der Nachteil ist daß der AVR dann ein paar mA
mehr Strom haben will.
Roland
Roland Z. wrote:
> Hallo,>> ...> Um die Sache um einiges Stabiler zu machen würde> ich die CKOPT-Fuse programmieren (heißt in einigen Proggersoftware auch> "Full Amplitude") damit schwingt der Oszillator mit vollem Hub und ist> somit um einiges Stabiler.> ...>> Roland
Du bist mein Held. Die CKopt Fuse gesetzt und der Atmega lässt sich
nicht mehr stören, bzw. alles funktioniert wie angedacht.
Danke und Gruß
Olaf
Eine eigene Frage?
Dieser Thread ist über 19 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
