Forum: Mikrocontroller und Digitale Elektronik Software Watchdog


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von techniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Heiko G. (heikog)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Z.B. über einen IO-Pin, Taste oder Remote das Watchdogreset abschalten.

von techniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von THOR (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von techniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sollte der Watchdog Timer die höchste Prorität haben?

von THOR (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das wäre vorteilhaft, ja.

von techniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

von techniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der Mikrocontroller hat intern bereits eine Watchdog Funktionalität. 
Also kein Software Watchdog. Ich hab da was durcheinander gebracht :-)

von THOR (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von techniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich benutze den XMC4700 Mikrocontroller von Infineon

von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von techniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ok

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ruediger A. (Firma: keine) (rac)


Bewertung
1 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.