|
Anzeige
|
Software Watchdog
Gast
#4948198
Hallo, auf einem Mikrocontroller habe ich einen Software Watchdog implementiert. Um das Verhalten genauer zu Testen müsste ich ein Fehler provozieren. WIe könnte ich so einen Fehlerfall auf einem Mikrcontroller erzeugen damit der Watchdog ausgelöst wird? Das kommt ja darauf an welche Fehler der Watchdog abfangen soll. Normalerweise wäre das eine Endlosschleife, Interrupts die disabled bleiben, Sleep-Modes aus dem die CPU nicht mehr aufwacht... zumindest die Reaktion auf eine Endlosschleife oder das Abschalten der Interrupts kann man in einer Testroutine überprüfen. Z.B. über einen IO-Pin, Taste oder Remote das Watchdogreset abschalten.
Gast
#4948216
Ich habe in meiner Applikation einen Ethernet Stack laufen. Da kann es eventuell passieren das der Mikrocontroller von außen nicht mehr angepingt werden kann.
Gast
#4948222
techniker schrieb: > Hallo, auf einem Mikrocontroller habe ich einen Software Watchdog > implementiert. Um das Verhalten genauer zu Testen müsste ich ein Fehler > provozieren. WIe könnte ich so einen Fehlerfall auf einem Mikrcontroller > erzeugen damit der Watchdog ausgelöst wird? Wie hast du das denn gemacht, ein Task der regelmäßig abgearbeitet wird und auf Flags anspringt? Dann isses recht einfach, mach nen anderen Task, lass den ne Endlossschleife machen und guck ob der WD tut was er soll. Und: Guck wie lang das dauert. Und dann noch Prüfung des Negativverhaltens: Kann eine höher priorisierte ISR/Task 100% CPU Zeit haben weil der WDR-Task dann nie drankommt?
Gast
#4948228
Sollte der Watchdog Timer die höchste Prorität haben?
Gast
#4948235
Das wäre vorteilhaft, ja.
Gast
#4948238
Ok. In der while Schleife vom Watchdog sollte zyklisch der Watchdog wirder zurückgesetzt werden. Wenn dies nicht passiert dann soll ein Software Reset ausgelöst werden.
Gast
#4948240
Heiko G. schrieb: > zumindest > die Reaktion auf eine Endlosschleife oder das Abschalten der Interrupts > kann man in einer Testroutine überprüfen. Wie soll ein SoftwareWDT einen hängenden Prozessor erkennen, wenn die Interrupts abgeschaltet sind? Meiner bescheidenen Meinung nach ist ein SoftwareWDT seinen Namen nicht wert. Zweckmäßig: Ein Hardware WDT, egal ob auf dem µC, oder extern. Alles andere würde ich eher "Timeout" nennen.
Gast
#4948251
Der Mikrocontroller hat intern bereits eine Watchdog Funktionalität. Also kein Software Watchdog. Ich hab da was durcheinander gebracht :-)
Gast
#4948261
techniker schrieb: > Der Mikrocontroller hat intern bereits eine Watchdog > Funktionalität. > Also kein Software Watchdog. Ich hab da was durcheinander gebracht :-) Gut, dann hast du einfach dein __asm("wdr"), nich? Wenns ein AVR ist. Wenn der WD-Timer überläuft, wird die ISR angesprungen oder ein Reset ausgelöst, siehe Datenblatt. Das testet man eigentlich nicht, da kann man von ausgehen dass es funktioniert. Aber wie gesagt: Ne Endlosschleife wo kein wdr aufgerufen wird, muss früher oder später den WD-Reset bzw. die ISR auslösen. Arduino F. schrieb: > Meiner bescheidenen Meinung nach ist ein SoftwareWDT seinen Namen nicht > wert. Wenn man das richtig implementiert, ist ein Software WDT genauso gut wie einer in Hardware. Hardware kann auch Bugs haben.
Gast
#4948263
Ich benutze den XMC4700 Mikrocontroller von Infineon
Gast
#4948264
Hi >Ich habe in meiner Applikation einen Ethernet Stack laufen. Da kann es >eventuell passieren das der Mikrocontroller von außen nicht mehr >angepingt werden kann. Dann hast du einen Software- oder/und Hardwarefehler. Bring das Zeug (ohne WD) erst mal fehlerfrei zum Laufen. Dann, und nicht früher, kannst du dir Gedanken über einen WD machen. MfG Spess
Gast
#4948266
Ok
Gast
#4948278
THOR schrieb: > Wenn man das richtig implementiert, ist ein Software WDT genauso gut wie > einer in Hardware. In Echt? Das musst du mal meinen SPSen und dem TÜV Menschen, der die Anlagen abnimmt erzählen. THOR schrieb: > Wenn man das richtig implementiert, ist ein Software WDT genauso gut wie > einer in Hardware. Hardware kann auch Bugs haben. Hard- und Softwarewatchdogs sind zwei verschiedene Dinge, die verschiedene Fehler zu korrigieren versuchen. Nehmen wir an, zwei tasks stehen im deadlock, aber die Nachtriggertask des HW watchdogs ist von dem deadlock nicht betroffen - also wird der HW WD immer fröhlich nachgetriggert, aber das System tut trotzdem nicht richtig. HW watchdogs sind genau in den Szenarios sinnvoll, in dem das Nachtriggern durch eine zu lang dauernde Berechnung höherer Priorität (also höhere Taskpriorität oder Interrupt) unterdrückt wird. Systemweite semistabile Zustände können von HW WDs nicht abegfangen werden. SW Watchdogs (die ich eigentlich lieber "Monitore" nenne) prüfen, ob eine zu überwachende task regelmäßig genug an die CPU kommt (was natürlich voraussetzt, dass die task so gebaut ist, dass sie im Normalbetrieb die Zeitvorgabe einhalten kann). Dazu zählt eine "Monitortask" (sinnvollerweise auch die task, die den HW WD nachtriggert) periodisch eine Variable herunter und setzt das System zurück (mglw. durch Unterdrücken des HW WD Nachtriggerns oder wie auch immer), wenn der Zähler 0 wird. Die zu überwachende Task setzt den Zähler periodisch wieder hoch. Dadurch werden im obigen Beispiel die im Deadlock stehenden tasks irgendwann die Monitor Task dazu bringen, den Zähler auf 0 zu bringen und damit den SW WD auslösen. Ähnlicher Effekt und verwandte Strategie, aber eben zwei unterschiedliche Mechanismen. FWIW, ich diskutiere den Mechanismus recht ausführlich in Kapitel 8 meines Buches. Antwort schreiben |
Anzeige
|
