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.
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.
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?
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.
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.
Der Mikrocontroller hat intern bereits eine Watchdog Funktionalität. Also kein Software Watchdog. Ich hab da was durcheinander gebracht :-)
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.
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
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.
:
Bearbeitet durch User
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.