Hallo zusammen, u.a. in der Automobilelektronik werden ja besonders kritische Schaltungen mit einem externen Watchdog-IC auf ihre Funktion hin überwacht.Diese Watchdog-IC's werden meist von einem µC getriggert. Hier nun meine Frage: Ist es erlaubt, daß die Trigger-Impulse in einer (Timer)Interrupt Routine des µC's ausgelöst werden? Denn wenn sich der µC irgendwann mal im Programmcode verrannt hat und "Mist baut", springt er bei Ablauf des Timers immer an den entsprechenden Vektor und führt die dazugehörige Interrupt Routine aus. Anschließend springt er wieder dahin zurück, wo er hergekommen ist. Eine Fehlfunktion des µC's wird somit vom Watchog-IC nicht erkannt (passiert auch, wenn der µC in einer Schleife auf ein Ereignis wartet, welches nie kommen wird). Weiß hier jemand wie die Watchdogs in der Praxis getriggert werden? Ich hoffe ihr versteht was ich meine. Gruß Dumpfi
Genau aus diesem Grund triggert man den WD niemals aus einer ISR. Dazu sucht man sich eine Stelle im Hauptprogramm, welche im Normalfall zyklisch aufgerufen wird. Verennt sich das Programm im Nirwana, wird die entspechende Funktion nicht mehr aufgerufen. Man muss dann natürlich lange Wartezeiten auf ext. Ereignisse entsprechend programmtechnisch richtig behandeln. Also nicht stur drauf warten, sondern eben auch zyklisch abfragen, ob sich was getan hat.
Hallo crazy horse, vielen Dank für deine Antwort. Wenn man den Watchdog aus der Hauptschleife heraus zyklisch triggert, dann müßte man deren Zykluszeit nach jeder Änderung genau ausrechnen/simulieren/messen. Wäre es auch denkbar, daß man nur aus einer Timer-ISR heraus den Watchdog triggert, wenn eine entsprechende volatile-Variable in der Hauptschleife auf TRUE gesetzt worden ist (nach dem Triggern wird die Variable natürlich wieder auf FALSE gesetzt). Damit wird doch sichergestellt, daß nur dann der Watchdog getriggert wird, wenn die Hauptschleife noch ordnungsgemäß durchlaufen wird. Gruß Dumpfi P.S.: Es steht hier bei mir hinter dieser Thematik kein Projekt dahinter. Ich bin einfach nur beim Surfen über ein paar Watchdog-IC's auf der Homepage von Atmel gestolpert und frage mich wie diese korrekt im System eingesetzt werden.
"Wenn man den Watchdog aus der Hauptschleife heraus zyklisch triggert, dann müßte man deren Zykluszeit nach jeder Änderung genau ausrechnen/simulieren/messen." Nö, braucht man nicht. Es muss nur sichergestellt sein, dass die WD-Zeit länger ist als der normale Programmlauf. Ob der WD nun 1ms oder 200ms nach dem Hänger zuschlägt, ist in 99% der Fälle wurscht, Hauptsache, der MC findet überhaupt einen Ausweg. "Wäre es auch denkbar, daß man nur aus einer Timer-ISR heraus den Watchdog triggert, wenn eine entsprechende volatile-Variable in der Hauptschleife auf TRUE gesetzt worden ist (nach dem Triggern wird die Variable natürlich wieder auf FALSE gesetzt). Damit wird doch sichergestellt, daß nur dann der Watchdog getriggert wird, wenn die Hauptschleife noch ordnungsgemäß durchlaufen wird. " Das ist doch mehr oder weniger das gleiche, da kannst du doch gleich an der Stelle, wo du deine Variable auf true setzt, den WD triggern. Es kommt bei einem WD nicht darauf an, den in möglichst exakten Zeitabständen zu triggern, sondern eine Max-Zeit nicht zu überschreiten. Ich persönlich arbeite bei ext. Watchdogs nach folgender Weise: Funktion 1: WD_out=1; . . Funktion 2: WD_out=0; . . Um einen WD-Reset zu verhindern, müssen also 2 Programmteile aufgerufen werden, um die Triggerflanken zu erhalten. Theoretisch ist denkbar, dass der MC der Schleife hängt, die den WD triggert - das kann nach obiger Vorgehensweise nicht passieren. U
Hallo crazy horse, vielen Dank für deine Antwort. Für "normale" Watchdog-IC's hast du natürlich recht wenn du sagst, daß die genaue Triggerzeit nicht so wichtig ist. Wie sieht die Sache aber aus, wenn ich einen Fensterwatchdog habe, wie z.B. den U5021M von Atmel? Bei diesem IC ist es so, daß ein Triggersignal nur dann gültig ist, wenn es in einem definierten Zeitfenster auftritt (entsprechender Ausschnitt des Datenblattes ist im Anhang). Dann muß ich doch genau wissen, wann ich triggern darf und wann nicht. In diesem Fall wäre es halt geschickt, wenn ich in der Hauptschleife eine Variable setze, die mir sagt, daß noch alles in Ordnung ist und abhängig von dieser Variable in einer Timer-ISR triggere. Mit Hilfe des Timers treffe ich dann immer das offene Trigger-Fenster und mit der Variablen aus der Hauptschleife weiß ich, daß das Programm tatsächlich noch läuft und nicht nur meine ISR immer aufgerufen wird. Würde diese Vorgehensweise genügen um mit Sicherheit die Funktionalität meiner Schaltung zu gewährleisten? Gruß Markus
prinzipiell ja. Typischerweise hat man ja aber auch einen zyklischen Task, der in konstanten Zeitabständen durchgeführt wird - darin ist der WD-Retrigger am besten aufgehoben. Wenn du mehrere Tasks hast, die sich unabhängig voneinander aufhängen können, dann kannst du auch mit weiteren Hilfsvariablen diese Tasks überwachen. WD wird dann nur getriggert, wenn alle Hilfsvariablen "ok" signalisieren, sonst mistriggern. Wenn die Tasks unterschiedliche Aufrufzyklen haben, dann in der zentralen WD-Instanz die Hilfsvariablen auf einen Startwert setzen, der abhängig von der Zykluszeit ist und im Task selbst, diesen Wert bei jedem Durchlauf dekrementieren. Ist der Wert irgendwann auf 0 gesunken, dann WD nicht mehr triggern oder mistriggern (dann gewinnst du noch ein paar ms Startupzeit...). ----, (QuadDash).
Hallo, ich danke euch beiden für eure guten und vor allem schnellen Antworten. Ich habe dank eurer Hilfe ein weiteres Teilsystem von µC-Schaltungen verstanden. Vielen Dank. Gruß Dumpfi
Wenn man noch ein Online-Update durchführen möchte, sollte man auch den zugehörigen Ausgang über ein XOR-Gatter triggern lassen. Ansonsten kommt mitten im Flash-Update ein Reset.
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.