Wie triggert man einen Watchdog-IC im System?

[dumpfi (Gast)]

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

[crazy horse (Gast)]

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.

[dumpfi (Gast)]

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.

[crazy horse (Gast)]

"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

[dumpfi (Gast)]

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

[---- (Gast)]

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).

[dumpfi (Gast)]

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

[Rolf (Gast)]

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.