Korrekte Möglichkeiten zur Implementierung von standardmäßig eingebauten Watchdog-Timern

Ich bin etwas neu in der Verwendung von Anwendungen, die Watch-Dog-Timer verwenden, und ich bin bereit, zum ersten Mal einen zu verwenden. Ich verwende pic18f26j50 und es hat einen internen Watchdog-Timer, der ein Limit von 2 ms hat und auf bis zu 2 Minuten erweitert werden kann.

Ich verstehe, dass der ganze Zweck der Verwendung interner Watchdog-Timer darin besteht, eine versehentliche Codesperre zu verhindern. Daher würde ich gerne wissen, auf welche Weise der Watchdog-Timer getestet und bewiesen werden kann, dass es ausfallsicher sein könnte, ihn richtig zu treten ohne Fehler.

Ich vertraue darauf, dass Ihr Input mir hilft, Testroutinen zu schreiben, damit ich die Funktionen verstehen kann, und ich möchte auch über mögliche Fallstricke informiert werden.

Und ich vertraue darauf, dass der Wachhund normalerweise in der Hauptleitung gelöscht wird, und eine weitere Frage, die ich annehme, ist, ob ich bestimmte Module A, B, CN habe, die in der Hauptleitung aufgerufen werden. Was sind die Anforderungen an einen Designer, damit der Watchdog-Timer dem Standard entspricht und worauf muss der Entwickler in einem solchen Fall richtig achten?

Antworten (2)

Man könnte wahrscheinlich ein Buch darüber schreiben – ich werde versuchen, die Höhepunkte aufzuzählen.

Das WDT ist ein Tool, das verwendet werden kann, um einige Anforderungen auf Systemebene zu erfüllen, und diese Anforderungen sind die Hauptmotivation. Sie können sicherheitsrelevant sein oder dem Wunsch entspringen, die Belästigung des Benutzers zu verringern. Es gibt andere Tools wie Uhrenmonitore, externe WDTs, Redundanz, Interrupts beim Zugriff auf falsche Speicherstellen, Verriegelungen verschiedener Art usw.

Ein WDT wird nichts verhindern – es kann verwendet werden, um die Wiederherstellung nach einer Systemstörung zu unterstützen. Wenn ein WDT-Timeout ausgelöst wird, wissen Sie, dass etwas wirklich Schlimmes passiert ist, aber Sie wissen nicht genau, was, also müssen Sie eine Art Wiederherstellungsvorgang einleiten. Der Prozessor könnte sich abgeschaltet und alle möglichen Dinge getan haben – Speicher (RAM oder EEPROM) beschädigt, SFRs auf falsche Werte umgeschrieben, Ausgänge auf unerwünschte Zustände gesetzt usw. Das erste, was Sie tun müssen, ist, das System in einen Zustand zu versetzen "sicherer" Zustand, wenn dies ein Problem darstellt und möglich ist. Beispielsweise sollte eine 10-kW-Heizung in den meisten Fällen „aus“ geschaltet werden (es gibt Fälle, in denen „ein“ besser ist). Einige Dinge (denken Sie an einen Drohnen-Autopiloten) haben möglicherweise keinen sicheren passiven Zustand, und Sie müssen möglicherweise den Betrieb wieder aufnehmen und versuchen, sich zu erholen.

Vor dem Zurücksetzen des WDT (wie Sie sagen, es sollte in der Hauptroutine passieren) sollten Sie so viele Dinge wie möglich überprüfen, nicht nur, dass Sie zur Reset-Routine gekommen sind. Möglicherweise möchten Sie bestätigen, dass sich bekannte Werte wie SFRs nicht geändert haben (oder sie neu schreiben, wenn dies nicht stört). Es ist keine gute Idee, sich auf Standardwerte beim Einschalten zu verlassen. Es ist möglich, Flags zu setzen, die den fehlerfreien Abschluss wichtiger Operationen anzeigen. Sie können die Flags dauerhaft machen (einen Fehler markieren und ihn nie zurücksetzen). Komplette Heilung. Es ist eine gute Praxis, den WDT-Reset durch Sprünge eingezäunt zu haben, damit Sie nicht versehentlich darauf stoßen (z. B. durch Ausführen von NOPs in nicht verwendetem Speicher).

Was das WDT-Timeout angeht, möchten Sie es kurz genug machen, dass nichts Schlimmes passieren kann, oder das WDT wird nicht so nützlich sein. Bei einem thermischen System sind einige Sekunden möglicherweise kein Problem. Im Falle eines Bewegungssteuerungssystems könnten Millisekunden besser sein. Zu häufig und Sie haben möglicherweise Probleme, es häufig genug zurückzusetzen.

Es ist besser, einen WDT zu haben, der nicht von der Firmware deaktiviert werden kann und nicht auf ein zu langes Timeout eingestellt werden kann (was fast dasselbe ist wie eine Deaktivierung). Normalerweise haben gut konzipierte Prozessoren einen gewissen Schutz gegen einen fehlerhaften Prozessor, der so etwas tut.

In dem Fall, in dem Sie es sehr häufig zurücksetzen müssen, aber eine sehr langsame Regelschleife ausgeführt wird, können Sie ein Flag oder einen Timer verwenden, um ein Problem in der langsamen Routine anzuzeigen und das WDT zurückzusetzen, wenn es abläuft. Das fügt der langsamen Routine im Wesentlichen eine Software-WDT hinzu. Ein Beispiel dafür könnte ein Bewegungssystem sein, das im Hintergrund einen selbstabstimmenden Algorithmus ausführt. Sie benötigen eine sehr schnelle WDT, um zu verhindern, dass das System unerwünschte Bewegungen ausführt, aber die Selbstoptimierung dauert länger.

Gibt es einen Fehler bei der Verwendung eingebauter WDTs? Oder Sie sollten bei der Implementierung des Peripheriegeräts, dem ich vertraue, korrekt und vorsichtig sein.
Selbst bei richtiger Implementierung kann der On-Chip-Typ nur begrenzt viel leisten. Wenn es einen Hardwarefehler im Chip oder den Verbindungen gibt, können sie nicht helfen. Sind sie getestet? Wenn die WDT-Uhr (unabhängige Uhr) ausfällt, woher wissen Sie das? Ich musste externes WDT in sicherheitskritischen Systemen verwenden (natürlich kann das interne gleichzeitig verwendet werden).

Ja, Sie haben Recht, dass ein Watch-Dog-Timer (WDT) verwendet wird, um jeden Code abzufangen, der versehentlich dazu führen würde, dass der Mikrocontroller aufgrund einer Endlosschleife blockiert.

Typischerweise sind Hauptroutinen in eingebettetem Code etwa so strukturiert:

void main ()
{
    initialization();

    while (1)
    {
       routine_a();

       routine_b();

       // etc.

       CLear_WDT();
    }

    // never get to here
}

Natürlich müssen Sie am Ende dieser Schleife (die ich Clear_WDT nenne) einen Aufruf zum Löschen des WDT haben, wie gezeigt. Aber oft müssen Sie zusätzliche Aufrufe dieser Funktion in die untergeordneten Routinen einfügen, wenn sie Code enthalten, dessen Ausführung besonders lange dauern kann (lang genug, um Ihr WDT sowieso auszulösen).

Manchmal müssen Sie möglicherweise einen Aufruf zum Löschen des WDT innerhalb einer While-Schleife platzieren. Hier ist zum Beispiel eine Schleife, die bis zu 20 Sekunden auf eine Antwort von einem Gerät der Gegenseite wartet:

i = 0;
while (i < 20)
{
    if (answer())
    {
        break;
    }
    delay_ms(1000);

    Clear_WDT();

    i++;
}

Hier müssen Sie durch Inspektion garantieren , dass die Schleife beendet wird, wenn das Timeout 20 Sekunden überschreitet (20 Mal durch die Schleife). Wenn der Aufruf von i++ fehlt, werden Sie die Schleife nie verlassen, aber Sie werden den WDT auch nicht auslösen. Beachten Sie, dass Watchdog-Timeouts bei allen Aufrufen von Funktionen auf niedrigerer Ebene (wie answer()) weiterhin ordnungsgemäß auftreten. es ist nur die High-Level-Schleife, die den Clear_WDT-Aufruf enthält, die von Bedeutung ist.

Setzen Sie im Allgemeinen keine Aufrufe von Clear_WDT in Interrupt-Routinen ein, insbesondere nicht in Timer-Interrupts, da dies den Zweck zunichte machen würde.

Das Testen eines WDT ist ziemlich einfach; Erstellen Sie einfach eine Endlosschleife, die keinen Aufruf von Clear_WDT enthält:

while (1)
{
}

und kleben Sie das irgendwo in Ihr Programm (an einer Stelle, die natürlich ausgeführt wird). Wenn es zu dieser Schleife kommt und nie weitergeht, wird es Ihr WDT starten.

Der Timeout-Wert für ein WDT muss lang genug sein, damit Sie keine Aufrufe von Clear_WDT über Ihren gesamten Code verteilen müssen, um zu vermeiden, dass das WDT ausgelöst wird, und kurz genug, um nützlich zu sein (ein zweiminütiges WDT ist nicht viel anders dass das System einfach abstürzt). Ich habe oft einen Wert zwischen 2 und 8 Sekunden verwendet.

Also sollte der Watchdog-Timer von Beginn des Tests an getestet werden und die Zeit für jedes Modul sollte in einem af/w-Dokument rechts dokumentiert werden. :) Das war hilfreich
Ja, ich empfehle, dass Sie am Anfang Ihres Hauptcodes (natürlich nach der WDT-Initialisierung) eine temporäre Endlosschleife einfügen und überprüfen, ob die WDT-Timer-Einstellung korrekt ist (wenn der WDT auf einige Sekunden eingestellt ist, ist dies der Fall einfach zu erledigen). Gehen Sie dann jede Ihrer Routinen durch, und wenn sie länger als ein paar hundert Millisekunden dauern, notieren Sie sich das und prüfen Sie, ob Sie zusätzliche Clear_WDT-Aufrufe hinzufügen müssen.