Unabhängiger Watchdog (IWDG) oder Window Watchdog (WWDG)?

Ich suche noch nach einer Antwort auf diese Frage:

Warum gibt es einen einfachen Watchdog (Independent Watchdog (IWDG)), während die stm32-MCUs einen perfekten Watchdog haben (ich meine Window Watchdog (WWDG))?

Ich fand diese Seite , die gesagt hat:

ST Microelectronics bietet eine Reihe von Cortex-M3-Geräten an. Der M3 ist bei Embedded-Geräten der unteren Preisklasse sehr beliebt, und der STM32F von ST steht stellvertretend für diese Teile (obwohl der WDT ein ST-Add-On ist und nicht unbedingt die Implementierungen anderer Anbieter widerspiegelt). Der STM32F verfügt über zwei verschiedene Schutzmechanismen. Ein "Independent Watchdog" ist ein hübsches Vanille-Design, das außer der einfachen Bedienung nur wenig zu bieten hat. Ihr Window Watchdog bietet jedoch einen robusteren Schutz. Wenn ein Countdown-Timer abläuft, wird ein Reset generiert, der durch erneutes Laden des Timers verhindert werden kann. Da ist nichts Besonderes. Wenn das Neuladen jedoch zu schnell erfolgt, wird das System ebenfalls zurückgesetzt. In diesem Fall wird "zu schnell" durch einen Wert bestimmt, den man in ein Steuerregister programmiert.

Ein weiteres cooles Feature: Es kann kurz vor dem Zurücksetzen einen Interrupt auslösen. Schreiben Sie ein bisschen Code, um den Interrupt zu blockieren, und Sie können Maßnahmen ergreifen, um z. B. das System in einen sicheren Zustand zu versetzen oder Daten für Debugging-Zwecke zu sichern. ST schlägt vor, den Watchdog mit dem ISR neu zu laden. Treten Sie also den Hund, damit kein Reset erfolgt. Nimm ihren Rat nicht an. Wenn das Programm abstürzt, funktionieren die Interrupt-Handler möglicherweise weiterhin normal. Und die Verwendung eines ISR zum erneuten Laden des WDT macht den gesamten Grund für einen Fenster-Watchdog ungültig.

und das :

Die neue Serie der STM32F4 Cortex ™ -M4-CPUs von STMicroelectronics verfügt über zwei unabhängige Watchdogs. Man läuft über einen eigenen internen RC-Oszillator. Das bedeutet, dass alle möglichen Dinge in der CPU zusammenbrechen können und der WDT weiterhin ausgelöst wird. Es gibt auch einen „Window Watchdog“ (WWDT), bei dem der Code häufig, aber nicht zu oft kitzelt. Dies ist eine sehr effektive Methode, um sicherzustellen, dass abgestürzter Code, der zufällig in den Schutzmechanismus geschrieben wird, kein WDT-Tickle verursacht und der WWDT kurz vor dem Zurücksetzen einen Interrupt erzeugen kann.

ok, schauen wir uns das Referenzhandbuch an :

Der STM32F10xxx verfügt über zwei integrierte Watchdog-Peripheriegeräte, die eine Kombination aus hohem Sicherheitsniveau, Zeitgenauigkeit und flexibler Verwendung bieten. Beide Watchdog-Peripheriegeräte (Independent und Window) dienen zum Erkennen und Beheben von Fehlfunktionen aufgrund eines Softwarefehlers und zum Auslösen eines Systemresets oder eines Interrupts (nur Window-Watchdog), wenn der Zähler einen bestimmten Timeout-Wert erreicht. Der Independent Watchdog (IWDG) wird von einem eigenen Low-Speed-Clock (LSI) getaktet und bleibt somit auch dann aktiv, wenn die Hauptuhr ausfällt. Die Uhr des Window Watchdog (WWDG) ist von der APB1-Uhr vorskaliert und verfügt über ein konfigurierbares Zeitfenster, das so programmiert werden kann, dass ungewöhnlich spätes oder frühes Anwendungsverhalten erkannt wird. Die IWDG eignet sich am besten für Anwendungen, bei denen der Watchdog als völlig unabhängiger Prozess außerhalb der Hauptanwendung ausgeführt werden muss. haben aber geringere zeitliche Genauigkeitsbeschränkungen. Der WWDG eignet sich am besten für Anwendungen, bei denen der Watchdog innerhalb eines genauen Zeitfensters reagieren muss.

Der Window Watchdog wird verwendet, um das Auftreten eines Softwarefehlers zu erkennen, der normalerweise durch externe Interferenzen oder durch unvorhergesehene logische Bedingungen verursacht wird und dazu führt, dass das Anwendungsprogramm seinen normalen Ablauf verlässt. Die Überwachungsschaltung erzeugt nach Ablauf einer programmierten Zeitspanne einen MCU-Reset, es sei denn, das Programm aktualisiert den Inhalt des Abwärtszählers, bevor das T6-Bit gelöscht wird. Ein MCU-Reset wird auch generiert, wenn der 7-Bit-Abwärtszählerwert (im Steuerregister) aktualisiert wird, bevor der Abwärtszähler den Fensterregisterwert erreicht hat. Dies bedeutet, dass der Zähler in einem begrenzten Fenster aktualisiert werden muss.

Wie Sie sehen, hat keiner von ihnen gesagt, warum es zwei Watchdog gibt. Wenn ich frage, was sind die Unterschiede zwischen den beiden Watchdog, werden Sie alle Funktionen zählen, die Sie oben sehen können, und wenn Sie die beiden vergleichen möchten, wird offensichtlich der Window Watchdog (WWDG) der Gewinner sein! Warum gibt es dann zwei Wachhund?

Ich möchte wissen, wann ich IWDG und wann WWDG verwenden soll?

und gibt es einen Grund, der uns sagt, warum sie die zweite Uhr so ​​nennen -> "Window Watchdog"?

Regelmäßige Watchdog-Timer müssen vor dem Timeout zurückgesetzt werden. Wenn Sie einen WDT von 100 ms haben, können Sie ihn alle 99,9 ms oder alle 10 us zurücksetzen, und es tritt keine Zeitüberschreitung auf.

Window-Watchdog-Timer haben ein Zeitfenster, innerhalb dessen sie zurückgesetzt werden müssen. Wenn Sie es zu früh oder zu spät (vom vorherigen Reset) zurücksetzen, wird der Prozessor zurückgesetzt.

Der Zweck, falls dies nicht offensichtlich ist, besteht darin, sicherzustellen, dass der Code, der die WDT zurücksetzt, der beabsichtigte Code ist und in der beabsichtigten Weise funktioniert. Eine Art von unvorhergesehenem Zustand, der hochfrequente WDT-Zurücksetzungen erzeugt, verhindert nicht, dass das System zurückgesetzt wird.

Das Ausführen eines WDT über die Systemuhr kann ein Problem sein. Wenn die Uhr ausfällt und keine unabhängige Uhrüberwachungsschaltung vorhanden ist, können schlimme Dinge passieren. Die unabhängige Uhr für den WDT bedeutet, dass der WDT zurückgesetzt würde, wenn das Ding aus irgendeinem Grund mit 1/10 Geschwindigkeit zu laufen beginnen würde (aber das Fenster WDT würde dies nicht tun).

Verwenden Sie beide, wenn Sie können.

Wie auf der Seite angegeben, ist das Zurücksetzen des WDT mit einem ISR in der Regel eine falsche Einstellung (kann jedoch akzeptabel sein, wenn der ISR vor dem Zurücksetzen des Timers überprüft, ob das Zurücksetzen der Firmware funktioniert).

Der Text, den Sie in die Frage eingefügt haben, enthält die Antworten, die Sie benötigen.

1. Sie verwenden IWDG, wenn Sie einen einfachen Watchdog benötigen oder wenn Sie einen vollständig unabhängigen Watchdog benötigen - IWDG hat eine eigene Uhr, WWDG leitet seine Uhr von einer der Busuhren ab - wenn sie ausfällt oder Ihre Software sie abschaltet, stirbt der Watchdog.
2. Sie verwenden WWDG, wenn Sie einen Watchdog benötigen, der nur innerhalb einer bestimmten Zeitspanne (Fenster) zurückgesetzt werden kann. Wenn Ihre Software den WWDG zu spät zurücksetzt, löst der WWDG einen Reset des Prozessors aus. Wenn Ihre Software den WWDG zu FRÜH zurücksetzt, wird auch der Prozessor zurückgesetzt.

Es wird ein "Fenster-Watchdog" genannt, weil nur ein Watchdog-Reset während eines bestimmten Zeitraums (Zeitfenster) verhindert, dass der Watchdog Ihren Prozessor zurücksetzt.

Beide machen ähnliche Jobs, aber sie machen sie anders. Was Sie brauchen, hängt von den Anforderungen ab, die Sie erfüllen müssen.

Es gibt einen weiteren Grund, den Fenster-Watchdog entweder anstelle oder zusätzlich zum unabhängigen Watchdog zu verwenden. WWDG hat einen Interrupt, den Sie einhängen können. Dies bedeutet, dass Sie, wenn Code in eine Schleife oder Fuge geraten ist, einen Haltepunkt im WWDG-ISR setzen und rückwärts arbeiten können, um herauszufinden, was die Firmware tat, als der Hund bellte.

Dies ist mit IWDG nicht möglich. Wie der Name schon sagt, ist das unabhängig vom Prozessor. Anstatt einen Interrupt auszulösen, wird einfach / RESET aktiviert und deaktiviert - was Ihnen nicht viele Hinweise gibt, warum es bellte. Ich würde dringend empfehlen, eine WWDG innerhalb Ihrer normalen Betriebsparameter sowie eine IWDG in einem viel längeren Zeitraum einzustellen, vielleicht maximal 2 * WWDG. Erstellen Sie eine Kick-Dog-Funktion, die beide Tritte ausführt. Auf diese Weise bellt die IWDG nur, wenn die WWDG als letzte Sicherung ebenfalls gesperrt wird.

Meine Einstellung dazu:

Verwenden Sie beide gleichzeitig, da sie nach verschiedenen fehlgeschlagenen Bedingungen suchen:

Der Independent Watchdog (IWDG) -Timer muss kontinuierlich zurückgesetzt werden, bevor eine Zeitüberschreitung auftritt . In der Praxis können Sie den Rücksetzcode einfach überall dort hinzufügen, wo Sie einen gültigen Programmstatus haben, oder einmal in der Hauptschleife, wenn Sie eine Hauptschleife haben, die ohne größere Verzögerungen häufig ausgeführt werden soll. Auf diese Weise kommt Ihr Aufruf zum Zurücksetzen des Timers (dies wird manchmal als "Streicheln", "Kitzeln" oder einfach als "Zurücksetzen" des Wachhundes bezeichnet) nicht rechtzeitig zustande. Dies bedeutet, dass Ihr Code entweder A) versehentlich hängen geblieben ist irgendwo, wo Sie es nicht vorausgesehen haben - eine Art unvorhergesehener Endlosschleifenstatus oder B) absichtlich irgendwo festgefahren, wo Sie es durch ein erzwungen habenassert()Funktionsaufruf mit einer eingebetteten Endlosschleife, zu der der Code wechseln soll, wenn eine wichtige Bedingung nicht erfüllt ist . Nun, da Ihre Assert-Bedingung falsch ist, bleibt Ihr Code absichtlich in einer Endlosschleife stecken, und der Watchdog setzt den Mikrocontroller zurück, um ihn wieder in einen gültigen Zustand zu versetzen. Beachten Sie auch, dass "der Independent Watchdog (IWDG) von einem eigenen Low-Speed-Clock (LSI) getaktet wird und somit auch bei Ausfall der Hauptuhr aktiv bleibt" (siehe ST RM0008 Referenzhandbuch p493 ).

Es scheint mir jedoch, dass der Window Watchdog (WWDG) -Timer so konzipiert ist, dass er nicht nach den oben beschriebenen Fällen sucht (in denen Ihr Code entweder unbeabsichtigt oder absichtlich [über eine Zusicherung] irgendwo "hängen bleibt"), sondern speziell nach dem Fall, in dem A) Ihr Code führt NICHT etwas aus, das er sollte . Mit anderen Worten, es liegt ein Fehler vor, der dazu führt, dass die Hauptschleife oder ein anderer Unterabschnitt des Codes zu schnell ausgeführt wird (oder dass dieser vollständig übersprungen wird), sodass Sie den Watchdog zu früh außerhalb seines Fensters zurücksetzen und die mcu zurückgesetzt wird. Oder B)Die andere Bedingung, die erkannt werden kann, ist eine fehlerhafte Timer-Einrichtung. Möglicherweise setzen Sie es in einem festen Intervall zurück, aber Ihr Timer, der zum Erstellen dieses Intervalls verwendet wird, ändert entweder versehentlich seine Konfigurationen an einer Stelle, die er nicht haben sollte, oder Sie konfigurieren es an erster Stelle falsch. Dann ist das Zeitintervall deaktiviert, Ihr fester Wert Durch das Zurücksetzen des Zeitintervalls wird der WWDG außerhalb seines Fensters zurückgesetzt (entweder zu früh oder zu spät), und die MCU wird zurückgesetzt, um Sie zu benachrichtigen und / oder den Zustand zu beheben.

Das ist meine Einstellung dazu. Gedanken oder Feedback sind willkommen.

"windowed" Watchdog ist nur ein normaler Watchdog, der einige Möglichkeiten für noch schlechtere Programmierpraktiken schützt. Wie bereits erwähnt, haben Sie einen "Zeitrahmen", in dem Sie normalerweise festlegen können, wo Ihr "Feed" bereitgestellt werden soll.

Keiner von ihnen ist kugelsicher, wenn Ihr Code in eine automatisch fortgesetzte Schleife eingegeben werden kann. Z.B. Wenn Sie vorhaben, basierend auf timer-bezogenen IRQs zu "füttern", kann dies eine äußerst schlechte Praxis sein, da Ihr Code in einigen Aufgaben / während des Mail-Threads hängen bleiben kann, während Interrupts Ihr WWDT weiterhin in der richtigen Reihenfolge füttern können.

Tatsächlich können Sie Interrupts verwenden, um WWDT zu füttern, wenn Sie Ihre IRQ-Priorität unter dem normalen Ausführungscode senken können, wie dies bei MIPS (Microchip) möglich ist.

Wenn Ihr Code lebenserhaltend, kritisch usw. ist, löschen Sie einfach alle und verwenden Sie externes WDT (basierend auf Fragen und Antworten).