Einfrieren des STM32F7-Geräts: Zugriff auf Register nicht möglich

Wenn der Debugger gesperrt ist, vorausgesetzt, die Stromversorgung/Taktung ist in Ordnung, dann ist das wahrscheinlichste Ergebnis ein interner Bus-Deadlock. Wenn Sie beispielsweise ein externes XIP-EEPROM haben und das Gerät falsch konfiguriert haben, kann das Peripheriegerät hängen bleiben, wenn Sie auf bestimmte Adress-/Datenmuster treffen.

Möglicherweise können Sie nach dem Zurücksetzen immer noch RAM-Informationen lesen (oder eine Ablaufverfolgung hinzufügen, um etwas in den RAM zu kopieren). Die zentralen Architekturregister werden nicht zurückgesetzt (es sei denn, Sie haben einen hochzuverlässigen sicherheitsspezifischen Teil). Wenn Sie also ein B selfin den Reset-Handler einfügen (vorausgesetzt, der Debugger „Halt nach Reset“ funktioniert nicht), sollte Ihr alter Zustand erhalten bleiben .

Sie können den ETM-Trace verwenden, um den Echtzeit-Trace zu erfassen, und wenn Sie den Trace im ETB erfassen, können Sie diesen nach dem Zurücksetzen einfach auslesen (auch hier sollte er dauerhaft sein), ohne dass eine Sonde erforderlich ist (aber möglicherweise geht der Pufferzeiger verloren, also Sie möglicherweise muss die Ablaufverfolgung manuell verarbeitet werden). Die ETM-Ablaufverfolgung zeigt Verzweigungen (Adressen für alle indirekten Verzweigungen) und Ausnahmen (einschließlich Sperren) an - Sie sollten also einen ziemlich genauen Hinweis darauf erhalten, was das letzte Ding war. Insbesondere "beobachtet" die Ablaufverfolgung nur den Kern, sodass Befehle zurückgezogen werden, ohne von der Busaktivität beeinflusst zu werden. Die DWT könnte auch etwas Nützliches geben - je nachdem, was tatsächlich fehlschlägt.

Wie in einem der Kommentare erwähnt, können Sie zumindest mit MDK eine Verbindung zu einem "heißen" laufenden Ziel herstellen (ohne Zurücksetzen / Anhalten, ohne Code-Download), da der Debug-Port ein vollständig asynchroner Busmaster ist, der in den Kern eingebettet ist . Dies gibt Ihnen die Möglichkeit, den Speicherstatus auf einem Gerät mit langer Betriebszeit (aber nicht Kernregister) mit minimalem Eingriff zu prüfen, und dies kann wertvoll sein, um eine Diagnose zu bestätigen. Sie könnten sogar eine regelmäßige Abfrage von Speicherorten skripten, wenn dies relevant ist.

Da sich der Debug-Port schließlich wie der Kern verhält, können Sie viele Bus-Deadlock-Fehler nachahmen, indem Sie einfach das Debugger-Speicherfenster verwenden.

Ich empfehle Ihnen, nicht sofort zu irgendwelchen Schlussfolgerungen zu kommen. Da Ihr Design proprietär ist, wissen wir nicht viel über die Hardware. Daher kann ich Ihnen einige allgemeine Tipps zur Fehlerbehebung vorschlagen.

1. Das Problem könnte ein Kurzschluss irgendwo auf der Platine oder eine offene Verbindung oder vielleicht eine lockere Verbindung sein. Wir wissen nicht, was es sein könnte. Reinigen Sie also zuerst die gesamte Platine mit Isopropylalkohol (auch bekannt als PCB-Reiniger), reiben Sie sie gut mit einer Zahnbürste ab und wischen Sie dann mit Kimwipes den Schmutz / Staub / Metallteile usw. ab. Überprüfen Sie, ob der uC funktioniert. Wenn dies nicht der Fall ist, überprüfen Sie die PCB-Nachreinigung auf gebrochene Spuren, beschädigte PCB-Pads, kalte Lötstellen usw. Vorzugsweise sollten Sie in diesem Stadium versuchen, die gesamte Platine zu überarbeiten, um das Problem „lockere Verbindungen/Verbindungen“ zu beseitigen. Überprüfen Sie, ob der uC danach funktioniert.

2. Wenn der uC immer noch nicht funktioniert, überprüfen Sie grundlegende Dinge wie Schwankungen der Stromversorgung, Rauschen auf den Signalleitungen, Taktimpulse des uC usw. Verwenden Sie ein DSO, um die Taktimpulse und die Reset-Leitung zu überwachen. Auch auf Durchgang an allen Steckern prüfen. Wackeln Sie an den Kabeln, wenn der uC läuft, und prüfen Sie, ob das Problem behoben ist. Überprüfen Sie diese Dinge und versuchen Sie es dann erneut am uC.

3. Wenn das Problem dadurch nicht behoben wird, überprüfen Sie die Software. Flashen Sie den Code auf einem neuen uC (kein neues Entwicklungsboard!). Erstellen Sie Ihr eigenes Barebone-Entwicklungsboard. Mit Barebones meine ich keine angeschlossenen Peripheriegeräte, keine externen Schaltkreise. Nur die Uhr und einige Regler, das war's! Sie müssen sicherstellen, dass der Code den uC nicht einfriert. Das Eliminieren der externen Peripheriegeräte beseitigt die von ihnen verursachten Probleme (falls vorhanden). Jetzt wird also Ihre Software getestet. Wenn Sie Ihr eigenes Barebone-Entwicklungsboard erstellen, blinken Sie einen LED-Blinkcode, um sicherzustellen, dass es funktioniert. Flashen Sie dann Ihre Software auf dem uC und prüfen Sie, ob der uC einfriert oder nicht. Wenn es dann glücklich ist, war es die Software, die das Problem verursachte. Nehmen Sie die notwendigen Änderungen in der Software vor und sorgen Sie dafür, dass sie auf dem Barebones-Entwicklungsboard funktioniert. Sobald es auf dem BB-Devboard perfekt funktioniert,

4. Wenn der uC immer noch einfriert, bedeutet dies, dass Sie möglicherweise einige „nicht zu berührende“ Registerbits des uC über die Software geändert haben. Überprüfen Sie Ihre Software und notieren Sie sich alle Register und Bits, die sie ändert. Stellen Sie sicher, dass die Software das uC auf sichere Weise verwendet.

5. Wenn das Problem weiterhin besteht, überprüfen Sie, ob das von Ihnen verwendete Flash-Tool ordnungsgemäß funktioniert oder nicht. Tun Sie dies, indem Sie das Flash-Tool verwenden, um „gesunde“ uC-Boards zu debuggen. Wenn die Operation erfolgreich ist, ist Ihr Flash-Tool in Ordnung.

6. Wenn Ihre Software alle uC einfriert, liegt es wahrscheinlich an der Software. Überprüfen Sie, ob STMm32F7 so etwas wie "Verwenden Sie einen Hochspannungs-Parallelprogrammierer zum Zurücksetzen der Sicherungsbits" bietet. Bricked Atmel MCUs können mit HVPP wiederbelebt werden.

Probieren Sie diese Methoden aus und lassen Sie mich wissen, was passiert. Seien Sie beim Debugging-Prozess geduldig und beseitigen Sie Probleme nacheinander. Denken Sie daran, Codieren ist eine Fähigkeit, aber Debuggen ist eine Kunst!