Was könnte dazu führen, dass ein Mikrocontroller unerwartet zurückgesetzt wird?

Auf PIC- und dsPIC-Chips habe ich die folgenden Ursachen für unerwartetes Zurücksetzen beobachtet.

Hardware:

• Zurücksetzen des Pins auf Low oder Floating. Überprüfen Sie zuerst die offensichtlichen Dinge!
• ESD-Einkopplung 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 Oszilloskopsonden können als Antennen fungieren, Rauschen in den Chip einkoppeln und seltsame Resets verursachen. Ich habe Berichte über "ungültige Opcode"-Reset-Codes gehört.
• Schlechte Lötstelle/unterbrochene Brücke. Könnte eine Stromschiene verlieren oder kurzschließen, entweder auf dem Prozessor oder irgendwo anders auf der Platine.
• Störung/Rauschen der Stromschiene. Kann durch eine Reihe externer Probleme verursacht werden, einschließlich eines beschädigten Reglers oder eines Einbruchs in der vorgeschalteten Versorgung. Stellen Sie sicher, dass die Stromschienen, die den Prozessor versorgen, stabil sind. Möglicherweise ist irgendwo mehr Kappe erforderlich, möglicherweise eine Entkopplungskappe direkt am Prozessor.
• Einige Mikrocontroller haben einen Vcap-Pin, der nicht mit VDD verbunden sein darf und einen eigenen gemeinsamen Kondensator haben muss. Wenn dieser Pin nicht richtig angeschlossen wird, kann dies zu unvorhersehbaren Ergebnissen führen.
• Das Fahren eines negativen Analogeingangs über eine bestimmte Grenze hinaus verursacht einen Reset, der in RCON wie ein Brownout gemeldet wird. Dasselbe gilt möglicherweise für digitale Eingänge.
• Sehr hohe dV/dt in einem nahe gelegenen Stromrichter können einen Brownout-Reset verursachen. (Siehe diese Frage .) Ich habe dies in zwei Fällen gesehen, und in einem konnte ich es auf kapazitive Kopplung zurückführen. Ein IGBT schaltete 100–200 Ampere, und beim Abschalten sahen einige Rückkopplungsschaltungen ein paar Mikrosekunden lang Rauschen, das bei einem 3,3-V-Prozessor von 2 V auf über 8 V stieg. Das Erhöhen der Filterkappe auf dieser Feedback-Schiene führte dazu, dass die Resets aufhörten. Man könnte sich vorstellen, dass das Hinzufügen eines dV/dt-Filters über dem Transistor einen ähnlichen Effekt gehabt haben könnte.

Software:

• Watchdog-Timer. Stellen Sie sicher, dass der Watchdog-Timer oft genug gelöscht wird, insbesondere in Zweigen Ihres Codes, deren Ausführung möglicherweise lange dauert, wie EEPROM-Schreibvorgänge. Testen Sie dies, indem Sie den Watchdog deaktivieren, um zu sehen, ob das Problem verschwindet.
• Geteilt durch Null. Wenn Sie in Ihrem Code eine Divisionsoperation ausführen, stellen Sie sicher, dass der Divisor niemals gleich Null sein kann. Fügen Sie vor der Teilung eine Begrenzungsprü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 Stack ausgeht, was zu Abstürzen an ungewöhnlichen Punkten in der Codeausführung führen kann.
• Stapelunterlauf. Wenn Sie in Assembler programmieren, können Sie versehentlich mehr RETURNs ausführen, als Sie CALLs ausgeführt haben.
• Nicht vorhandene Interrupt-Routine. Wenn ein Interrupt freigegeben ist, aber keine Interrupt-Routine definiert ist, kann der Prozessor zurückgesetzt werden.
• Nicht vorhandene Trap-Routine. Ähnlich wie eine Interrupt-Routine, aber unterschiedlich genug, dass ich sie separat aufführe. Ich habe zwei separate Projekte mit dsPIC 30F4013 gesehen, die zufällig zurückgesetzt wurden, und die Ursache wurde auf eine aufgerufene, aber nicht definierte Falle zurückgeführt. Jetzt stellt sich natürlich die Frage, warum überhaupt ein Trap aufgerufen wird, was alles Mögliche sein kann, auch Siliziumfehler. Aber das Definieren aller Trap-Handler sollte wahrscheinlich ein guter früher Schritt sein, um unerklärliche Resets zu diagnostizieren.
• Funktionszeigerfehler. Wenn ein Funktionszeiger nicht auf eine gültige Position zeigt, kann das Dereferenzieren des Zeigers und das Aufrufen der Funktion, auf die gezeigt wird, einen Reset 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 ein Int) initialisierte. Das Komma wurde vertippt, also wurde der Funktionszeiger tatsächlich auf NULL-1 initialisiert. Gehen Sie also nicht davon aus, dass es einen gültigen Wert enthalten muss, nur weil es ein CONST ist!
• Ungültiger/negativer Array-Index. Stellen Sie sicher, dass Sie eine Begrenzungsprüfung für alle Array-Indizes durchführen, sowohl für die Ober- als auch für die Untergrenze, falls zutreffend.
• 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 das Verwenden des dereferenzierten Zeigers als LVALUE in einer Anweisung kann zu einem Absturz führen. Siehe diese Frage . Vermutlich gilt dies auch für andere undefinierte Verhaltensweisen.

Bei einigen dsPICs speichert das RCON-Register Bits, die die Ursache des Zurücksetzens angeben. Dies kann beim Debuggen sehr hilfreich sein.

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

• Übersprechen von Schaltleitungen in den RESET-Pin / die RESET-Leitung (kurz machen)
• Masseverschiebungen/Schleife verursacht durch Ein-/Ausschalten externer Hochstromlast
• Spannungsspitze wird nicht von der Stromversorgung gefiltert und ist zu kurz, um den richtigen RESET zu aktivieren
• Schalten externer Lasten durch den Mikrocontroller, was oben genannte Probleme verursacht (hauptsächlich bei induktiven Lasten wie Motor ein/aus, Relais oder alter 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 (wie Spannungsspitzen auf der Versorgungsleitung). Generell ist bei der Anbindung an eine Art Industrieumgebung Vorsicht geboten (mehr dazu unter: http://www.ichaus.biz/wp1_mcu_interface ). Pegelverschiebung auf IOs, Eingangsfilterung und weich schaltende Ausgänge müssen berücksichtigt werden. Hardwareseitig hat die Sauberkeit der Versorgungsleitungen erste Priorität. Dann RESET- und Oszillator-Pins, 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 auf Leitungen, die im schaltungsseriellen Programmiermodus ausgelöst werden, nicht genügend Pull-Ups verwendet werden, ist es manchmal möglich, diesen Modus zufällig aufzurufen. 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 wird und keine Programmierdaten gesendet werden. Dies ist ein Fehler, den ich gemacht und viel Zeit damit verbracht habe, ihn mit einem 16F876 zu finden.

Wenn Sie CMOS- oder TTL-Logikchips in Ihrer Schaltung verwenden, stellen Sie sicher, dass sie ü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 eine Spitze, die den Neustart des Mikroprozessors verursachte. Dann würde sich der Kreislauf wiederholen. Aus diesem Grund ist es auch eine gute Idee, am Anfang Ihres Codes eine offensichtliche Testsequenz (wie das mehrmalige Ein- und Ausschalten einer LED) einzufügen, damit Sie wissen, dass der Mikroprozessor arbeitet und Code ausführt.

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

Ich hatte ein Projekt mit einem Mikrocontroller, der sich sporadisch selbst zurücksetzte. Um es kurz zu machen, es stellte sich heraus, dass einige Optionen aktiviert oder deaktiviert werden mussten, da sonst Resets auftreten könnten. Das habe ich erst durch das Lesen der Errata herausgefunden, nachdem ich alles andere aufgegeben hatte.

Jetzt mache ich es mir zur Gewohnheit, die Errata zu lesen, bevor ich mich überhaupt entscheide, einen Chip zu verwenden, um zu wissen, worauf ich mich einlasse und ob ich damit umgehen kann. Leider hatte ich nach dem Abschluss niemanden, der mich über gängige Praktiken aufklärte, so dass ich viel in der realen Welt durch Misserfolg und Frustration gelernt habe.