Wie oft kommt es in der realen Welt tatsächlich zu Störungen bei AVRs, und es muss ein Watchdog-Reset durchgeführt werden?

Haben Sie jemals einen ansonsten glücklichen AVR gesehen, der spontan einen Fehler hatte und einen Reset benötigte?

Angenommen:

  1. ein schönes, stabiles Netzteil, das im angegebenen Bereich bleibt
  2. eine richtig dimensionierte Entkopplungskappe direkt zwischen Vcc und Masse
  3. normale (nicht zu laute) Haushaltsbedingungen

... was sind die realen MTB-Störungen?

Ich habe seit Jahren Hunderte von AVRs am Laufen und ich glaube nicht, dass ich jemals einen echten Fehler gesehen habe, aber vielleicht habe ich einfach Glück?

Beachten Sie, dass ich weiß , dass Sie immer einen Watchdog verwenden sollten, ich weiß. Beschämen Sie mich nicht - aber wenn die Wahrscheinlichkeit von Störungen sehr gering ist, könnte es Anwendungen geben, bei denen es sinnvoll wäre, den Watchdog möglicherweise nicht zu verwenden, um im Ruhezustand einen geringeren Stromverbrauch zu erzielen.

Beachten Sie auch, dass ich verstehe, dass der Watchdog Sie auch vor Firmware-Fehlern schützt, aber ich frage nur nach spontanen Hardware-Fehlern.

So wie Sie diese Funktionen für Software verwenden, da Software Fehler haben kann, kann auch Hardware Fehler haben.
Ein Watchdog wäre ohnehin nicht besonders gut darin, zufällige Hardware-Störungen zu verhindern – Sie können unmöglich jeden Zustand überwachen, der durch einen Blitzeinschlag oder einen Gammastrahl verändert werden könnte.
Wenn Sie davon ausgehen, dass der Fehler als spontane zufällige Änderung im flüchtigen Speicher (RAM oder ein Register [das den Programmzähler enthält]) auftaucht, dann denke ich, dass es möglich ist, Software zu schreiben, die sich von einem einzelnen Beschädigungsereignis erholen kann. Stellen Sie sich vor, Ihr Programm blinkt lediglich eine LED ein und aus. Wenn Sie den gesamten Programmspeicher mit den sich wiederholenden Anweisungen füllen, die zwischen Ein und Aus wechseln, können Sie meiner Meinung nach garantieren, dass das Blinken innerhalb einer einzigen Iteration nach der Beschädigung sein normales Muster wieder aufnimmt. Je komplizierter die Operation, desto schwieriger wird es.

Antworten (4)

Cosmic Ray Hits und SEU (Single Event Upsets) sind sehr real. Schlagen Sie einfach Daten über DRAM und die Notwendigkeit von ECC (Fehlerkorrektur) nach, und daraus sollten Sie in der Lage sein, ein Gefühl für die Wahrscheinlichkeit im Vergleich zur Fläche zu bekommen. Einige Prozesse sind weniger anfällig, und kleinere Prozesse, obwohl sie empfindlicher sind, weisen auch einen kleineren Erfassungsquerschnitt auf, manchmal ist das ein Vorteil und manchmal nicht.

Halten Sie diese Wachhunde am Laufen!

Ich akzeptiere vollkommen, dass diese Dinge passieren und wir sollten uns darüber Sorgen machen – ich versuche nur, ein ungefähres quantitatives Gefühl dafür zu bekommen, wie oft sie tatsächlich passieren. Was würden Sie für eine einzelne MPU als die mittlere Zeit zwischen Ereignissen in der realen Welt erwarten? 1 Jahr? 10 Jahre, 1 Million Jahre?
+1, aber diese Antwort würde mit einigen harten Zahlen verbessert. Die erste groß angelegte Studie zu DRAM-Fehlern, wie sie im Wikipedia-ECC-Speicherartikel erwähnt wird, hat durchschnittlich etwa 200 bis 600 DRAM-Fehler pro Jahr und Gigabit gemessen.
@davidcary Harte Zahlen? Hmmm, ich sage Ihnen was, Sie sagen, was das für ein Prozess ist, und lassen Sie mich das Layout sehen, und ich gebe Ihnen eine sehr harte Zahl. Bis man diese Details kennt, ist es nur eine Vermutung, mehr zu sagen.
@placeholder: OK, ich beiße. Können Sie mir einige Zahlen über den 350-Nanometer-Prozess ATMEGA88 nennen; Sie können das Layout bei Cesar ATMEGA88 Teardown sehen . Oder Sie könnten einen Satz über die Ihrer Meinung nach wichtigste Zahl aus der DRAM-Studie schreiben, auf die der Wikipedia-ECC-Speicherartikel verweist.
@davidcary sicher, ich werde warten, bis Sie die Brunnentiefen und die S / D-Implantationstiefen erkennen können, wenn Sie das nicht haben, reichen die Implantationsenergien aus. Und diese Bilder? Ich muss aktive oder auch nur eine Schätzung der Bohrlochplanansichtsbereiche und der Verbindungskantenlänge sehen.
Also was ist es? Um eine grobe Schätzung der durchschnittlichen Fehler pro Jahr zu erhalten, kann ich "einfach Daten über DRAM nachschlagen ... und daraus sollten Sie in der Lage sein, ein Gefühl für die Wahrscheinlichkeit gegenüber der Fläche zu bekommen."? Oder brauche ich auch eine Reihe von Informationen über Bohrlochtiefen oder Implantationsenergien, die in keinem der Datenblätter für die von mir verwendeten Teile jemals erwähnt werden?

Abhängig von der Umgebung und der Konfiguration. Es ist praktisch unmöglich zu garantieren, dass beispielsweise ein Blitzeinschlag in der Nähe nicht genügend EMI-Energie hat, um ein Problem zu verursachen. Sie können die Wahrscheinlichkeit durch gutes Design verringern, aber wenn sich das System nicht in einem Faraday-Käfig mit magnetischer Abschirmung und stark gefilterten Durchführungen befindet, besteht die Möglichkeit einer Störung. Bei Weltraumanwendungen hat das Erdmagnetfeld nicht die übliche Abschirmwirkung, daher sind zufällige Störungen wahrscheinlicher als auf der Erde (aber in beiden Fällen immer noch ungleich Null). Die Wahrscheinlichkeit, dass ein kleines in sich geschlossenes System (keine Ein- oder Ausgänge und batteriebetrieben) eine Störung sieht, ist viel geringer als bei angeschlossenen Kabeln.

Es gibt viele Systeme ohne Watchdogs und ohne ordnungsgemäße Reset-Schaltungen – wenn die Kosten für eine Sperre niedrig sind, kümmert es niemanden (schalten Sie einfach die Stromversorgung aus und wieder ein!). Wenn die Kosten hoch sind, kann die Verwendung eines WDT (intern oder extern), redundanter Prozessoren, mechanischer Überschreibungen oder anderer Mittel wünschenswert sein. Moderne Prozessoren (und besseres Softwaredesign) können das Zurücksetzen bei Anomalien auch ohne WDT unterstützen – zum Beispiel, wenn der Programmzähler außerhalb des Bereichs liegt. Ungenutzter Speicher kann mit Sprüngen zu einer Kaltstartroutine gefüllt werden, und andere Techniken können verwendet werden. Ich bin mir sicher, dass viele WDTs im Einsatz sind, die ziemlich nutzlos sind, weil sie von einem ISR oder so etwas Dummem gekickt werden.

Gibt es einen Namen für diese Techniken, vielleicht immunitätsbewusste Programmierung ?
Ich würde sie in die breitere Kategorie der sicherheitsbezogenen Software-Engineering-Techniken einordnen (weil dies oft der Motivator für die Verringerung des Risikos ist – Sachschäden oder mögliche Verletzungen oder Todesfälle von Personen). Noch nie was von "immunity-aware" gehört, danke.

Interessantes offizielles Wort von ATMEL:

Hallo Josh, ich verstehe, dass Sie besorgt sind, dass die Interrupt-Steuerbits zufällig umgedreht werden. Dies kann nicht passieren, es sei denn, sie werden irgendwie in der Firmware geändert oder das Gerät wird in einer lauten Umgebung aufbewahrt, die zu einer Flash-Beschädigung führen könnte. Um die Möglichkeit einer Flash-Korruption zu vermeiden, lesen Sie bitte Abschnitt 18.7 Flash-Korruption verhindern im Datenblatt des Geräts. Solange das Design den erwähnten Überlegungen zum Verhindern von Flash-Korruption entspricht, besteht keine Möglichkeit, dass die Interrupt-Steuerbits im Gerät beschädigt werden. Hoffe das klärt auf. Bitte melden Sie sich bei weiteren Fragen bei uns.

Mit freundlichen Grüßen, Ineyaa N Atmel Support-Team

AKTUALISIEREN

Ein Jahr später habe ich jetzt Zehntausende dieser kleinen AVRs auf der ganzen Welt, die rund um die Uhr laufen, und bisher habe ich keinen einzigen Fall einer spontanen Störung gesehen. Ziemlich erstaunlich. Wird nächstes Jahr aktualisiert!

Nun ... in typischer Umgebung und modernen Mikrocontrollern ist dies nicht oft der Fall.

So selten, dass es schwer zu messen und zu bestimmen ist.

Dies hängt von vielen Faktoren ab, einschließlich unerwünschter Ereignisse in der Produktionslinie. Hardwarefehler sollten niemals in unbeschädigten Mikrocontrollern auftreten, die in einer normalen Umgebung arbeiten, daher sagen Datenblätter nichts über die Zuverlässigkeit aus.

Ich persönlich verwende Watchdog nicht sehr oft, weil viele meiner Projekte einen solchen Schutz einfach nicht benötigen.

Wenn ich es verwende - ich verwende es für:

  • zusätzlicher Software-Fehlerschutz
  • teilweise beschädigter Mikrocontrollerschutz

Ich benutze es nur, wenn:

  • Mikrocontroller treibt einige teure Peripheriegeräte an (große Transistoren mit großer Last)
  • aus Sicherheitsgründen mit Schaltkreisen, die irgendwie mit dem Stromnetz zusammenhängen, oder wenn der Mikrocontroller etwas antreibt, das etwas zerstören oder jemandem schaden kann
  • wenn Daten, die in Mikrocontrollern verarbeitet werden, sehr zuverlässig sein müssen