Was kann dazu führen, dass ein Mikrocontroller unerwartet zurückgesetzt wird?

Eine besonders irritierende Art von Fehlern in einem mikroprozessorgesteuerten System besteht darin, dass der Mikroprozessor unerwartet zurückgesetzt wird. Ein wichtiges Tool zum Debuggen solcher Probleme ist eine Liste möglicher Ursachen. Was kann dazu führen, dass ein Mikrocontroller unerwartet zurückgesetzt wird?

Bei PIC- und dsPIC-Chips habe ich die folgenden Ursachen für ein unerwartetes Zurücksetzen festgestellt.

Hardware:

• Resetstift niedrig oder schwimmend. Überprüfen Sie zuerst die offensichtlichen Dinge!
• ESD-Kopplung in den Reset-Pin. Ich habe gesehen, dass dies passiert, wenn völlig unabhängige Geräte auf demselben Schreibtisch eingeschaltet werden. Stellen Sie sicher, dass am Reset-Pin genügend Kapazität vorhanden ist, möglicherweise bis zu 1 uF.
• ESD-Kopplung in andere Pins des Prozessors. Insbesondere Scope-Sonden können als Antennen fungieren, Rauschen in den Chip einkoppeln und ungewöhnliche Resets verursachen. Ich habe Berichte von "ungültigem Opcode" gehört, die Codes zurückgesetzt haben.
• Schlechte Lötverbindung / intermittierende Brücke. Möglicherweise geht eine Stromschiene am Prozessor oder an einer anderen Stelle auf der Platine verloren oder es liegt ein Kurzschluss vor.
• Stromschienenstörung / Rauschen. Kann durch eine Reihe von externen Problemen verursacht werden, einschließlich eines beschädigten Reglers oder eines Einbruchs der vorgeschalteten Versorgung. Stellen Sie sicher, dass die Stromschienen, die den Prozessor versorgen, stabil sind. Möglicherweise wird irgendwo mehr Kappe benötigt, möglicherweise wird die Kappe direkt am Prozessor abgekoppelt.
• Einige Mikrocontroller haben einen Vcap-Pin, der nicht an VDD angeschlossen werden darf und einen eigenen Kondensator gegen Masse haben muss. Wenn dieser Pin nicht richtig angeschlossen wird, kann dies zu unvorhersehbaren Ergebnissen führen.
• Wird ein negativer Analogeingang über einen bestimmten Grenzwert hinaus angesteuert, wird ein Reset ausgelöst, der in RCON wie ein Brownout gemeldet wird. Dies gilt möglicherweise auch für digitale Eingänge.
• Sehr hohe dV / dt in einem nahe gelegenen Stromrichter können zu einem Brownout-Reset führen. (Siehe diese Frage .) Ich habe dies in zwei Fällen gesehen und in einem Fall konnte ich es bis zur kapazitiven Kopplung verfolgen. Ein IGBT schaltete 100-200 Ampere, und beim Ausschalten stellten einige Rückkopplungsschaltungen einige Mikrosekunden Rauschen fest, das auf einem 3,3-V-Prozessor von 2 V auf über 8 V anstieg. Durch Erhöhen der Filterkappe auf dieser Rückkopplungsschiene wurden die Zurücksetzungen gestoppt. Man könnte sich vorstellen, dass das Hinzufügen eines dV / dt-Filters über den Transistor einen ähnlichen Effekt hatte.

Software:

• Watchdog-Timer. Stellen Sie sicher, dass der Watchdog-Timer häufig genug gelöscht wird, insbesondere in Zweigen Ihres Codes, deren Ausführung möglicherweise lange dauert, wie z. B. beim EEPROM-Schreiben. Testen Sie dies, indem Sie den Watchdog deaktivieren, um festzustellen, ob das Problem behoben ist.
• Geteilt durch Null. Wenn Sie eine Divisionsoperation in Ihrem Code ausführen, stellen Sie sicher, dass der Divisor niemals gleich Null sein kann. Fügen Sie vor der Unterteilung eine Begrenzungsüberprüfung hinzu. Vergessen Sie nicht, dass dies auch für Modulo-Operationen gilt .
• Paketüberfluss. Zu viele verschachtelte Funktionsaufrufe können dazu führen, dass dem System der dynamische Speicher für den Stapel ausgeht, was zu Abstürzen an ungewöhnlichen Punkten bei der Codeausführung führen kann.
• Stack underflow. Wenn Sie in Assembler programmieren, können Sie versehentlich mehr RETURNs ausführen, als Sie CALLs ausgeführt haben.
• Nicht existierende Interruptroutine. Wenn ein Interrupt aktiviert ist, aber keine Interruptroutine definiert ist, wird der Prozessor möglicherweise zurückgesetzt.
• Nicht existierende Trap-Routine. Ähnlich einer Interruptroutine, aber anders genug. Ich liste sie separat auf. Ich habe zwei separate Projekte mit dsPIC 30F4013 gesehen, die nach dem Zufallsprinzip zurückgesetzt wurden, und die Ursache wurde zu einem Trap verfolgt, der aufgerufen wurde, aber nicht definiert war. Jetzt haben Sie natürlich die Frage, warum überhaupt eine Falle aufgerufen wird, bei der es sich um eine beliebige Anzahl von Dingen handeln kann, einschließlich eines Siliziumfehlers. Das Definieren aller Trap-Handler sollte jedoch wahrscheinlich ein guter Anfang bei der Diagnose unerklärlicher Zurücksetzungen sein.
• Funktionszeigerfehler. Wenn ein Funktionszeiger nicht auf eine gültige Position zeigt, kann die Dereferenzierung des Zeigers und der Aufruf der Funktion, auf die verwiesen wird, ein Zurücksetzen verursachen. Eine amüsante Ursache dafür war, als ich eine Struktur mit aufeinanderfolgenden Werten von NULL (für einen Funktionszeiger) und -1 (für einen Int) initialisierte. Das Komma wurde getippt, sodass der Funktionszeiger tatsächlich auf NULL-1 initialisiert wurde. Nehmen Sie also nicht an, dass es sich nur um eine CONST handelt, die einen gültigen Wert enthalten muss!
• Ungültiger / negativer Array-Index. Stellen Sie sicher, dass Sie die Grenzwerte für alle Array-Indizes (obere und untere Grenze, falls zutreffend) überprüfen .
• Erstellen eines Datenarrays im Programmspeicher, das größer ist als der größte Abschnitt des Programmspeichers. Dies kann nicht einmal einen Kompilierungsfehler auslösen.
• Das Umwandeln der Adresse einer Struktur in einen Zeiger auf einen anderen Typ, das Dereferenzieren dieses Zeigers und die Verwendung des dereferenzierten Zeigers als LVALUE in einer Anweisung kann zu einem Absturz führen. Siehe diese Frage . Dies gilt vermutlich auch für andere undefinierte Verhaltensweisen.

Auf einigen dsPICs speichert das RCON-Register Bits, die die Ursache für das Zurücksetzen angeben. Dies kann beim Debuggen sehr hilfreich sein.

Der RESET-Pin muss ordnungsgemäß von einem Reset-Schaltkreis angesteuert werden, der die Über- / Unterspannung überwacht und ein ausreichend langes Reset-Signal erzeugt. Vor diesem Hintergrund kommen meine Erfahrungen mit einem unkontrollierten Hardware-Reset von:

• Übersprechen vom Umschalten von Leitungen in den RESET-Pin / die RESET-Leitung (kurz machen)
• Ground Shifts / Loop durch Ein- / Ausschalten der externen Hochstromlast
• Spannungsspitze nicht vom Netzteil gefiltert und zu kurz, um den richtigen RESET zu aktivieren
• Schalten externer Lasten durch den Mikrocontroller, was die oben genannten Probleme verursacht (hauptsächlich bei induktiven Lasten wie Motor ein / aus, Relais oder alte Lampe (Einschaltstrom)
• Spannungs- / Stromspitzen an einem der Mikrocontroller-Pins (am schlimmsten ist der Oszillator) können einen Rückstrom verursachen und das interne Register umschalten (genauso wie Spannungsspitzen auf der Versorgungsleitung). Bei der Anbindung an eine Art Industrieumgebung ist generell Vorsicht geboten (siehe http://www.ichaus.biz/wp1_mcu_interface ). Pegelverschiebung an E / A, Eingangsfilterung und Soft-Schaltausgänge müssen berücksichtigt werden. Das Reinigen der Versorgungsleitungen hat hardwareseitig oberste Priorität. Dann RESET und Oszillatorpins, dann IO-Leitungen. -mm

Eine weitere Möglichkeit, die ich in dieser Liste nicht gesehen habe, ist ein Gerät, das ICSP unterstützt. Wenn für Leitungen, die im seriellen Schaltungsprogrammiermodus ausgelöst werden, nicht genügend Pull-ups verwendet werden, kann dieser Modus manchmal zufällig aufgerufen werden. Dies führt kurze Zeit später zu einem Reset, wenn keine Programmaktualisierung an die vorgesehenen seriellen Empfängerleitungen gesendet wird. Ich vermute, dass ein interner Watchdog-Timer das Zurücksetzen erzwingt, wenn ICSP gestartet und keine Programmierdaten gesendet werden. Dies ist ein Fehler, den ich gemacht und viel Zeit damit verbracht habe, mit einem 16F876 zu suchen.

Stellen Sie bei Verwendung von CMOS- oder TTL-Logik-Chips in Ihrer Schaltung sicher, dass diese über ausreichende Entkopplungskondensatoren zwischen Vdd und Masse verfügen (normalerweise 0,1 uF). Ich habe einen CD4021 in einem Design verwendet, und als er verwendet wurde, verursachte er anscheinend einen Spitzenwert, der den Neustart des Mikroprozessors verursachte. Dann würde sich der Zyklus wiederholen. Aus diesem Grund ist es auch eine gute Idee, eine offensichtliche Testsequenz (z. B. ein paar Mal das Blinken einer LED) am Anfang Ihres Codes zu platzieren, damit Sie wissen, dass der Mikroprozessor arbeitet und Code ausführt.

Dies ist eines der seltenen Dinge, die auftauchen könnten:

Ich hatte ein Projekt mit einem Mikrocontroller, der sich sporadisch selbst zurücksetzte. Lange Rede kurzer Sinn, es stellte sich heraus, dass eine Option aktiviert oder deaktiviert werden musste, damit es nicht zu Rücksetzungen kam. Das habe ich erst herausgefunden, als ich die Errata gelesen habe, nachdem ich auf alles andere verzichtet hatte.

Jetzt mache ich es mir zur Gewohnheit, die Errata zu lesen, bevor ich mich dazu entscheide, einen Chip zu verwenden, um zu wissen, worauf ich mich einlasse und ob ich damit fertig werde. Unglücklicherweise hatte ich nach meinem Abschluss niemanden, der mich über die gängigen Praktiken aufklären konnte, so sehr war mein Lernen in der realen Welt durch Misserfolg und Frustration geprägt.