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
Olaf P. wrote:
> Die Tests die ich gerade durchführe sind sogenannte Burst Tests.
Was kann man sich darunter vorstellen?
@ 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
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.