ARM Cortex M3-Wie bestimme ich den program counter mit dem Wert vor einem hard fault?

Habe ich ein embedded-Projekt mit einem STM32F103 (ARM Cortex M3) ist, wird es immer eine gelegentlich schwer Fehler im release-Modus. Als Teil der Wiederherstellung, ich möchte zum abrufen der PC-Wert aus der Zeit vor dem hard fault und bewahren Sie Sie für spätere debugging in der Batterie gesichert region.

Wie würde ich das bestimmen Sie den Wert des program counter auf den Punkt der harte Schuld? Natürlich, der PC ist nun eingestellt, um seine Position innerhalb der hardfault-interrupt.

Wo sollte ich suchen? Gibt es eine Adresse für die normal-Modus-register-bank?

Dank!

Ich möchte auch wissen, aber Sie erhalten möglicherweise eine bessere Antwort auf chiphacker.com.

InformationsquelleAutor JeffV | 2010-09-21

  1. 6

    Cortex-M3 verwendet ein ganz anderes Modell der Ausnahmebehandlung aus der "classic" - ARM, z.B. es muss nicht "abort-Modus" erwähnt im anderen post. Ich schlage vor, Sie Lesen diese app beachten. Zum Beispiel, für die Hard Fault:

    Den Wert der SCB->BFAR zeigt die Speicher-Adresse, verursacht ein Bus Fehler
    und ist gültig, wenn das bit BFARVALID in der SCB->CFSR-register wird gesetzt. Die
    Wert von SCB->MMFAR zeigt die Speicher-Adresse, verursacht eine Erinnerung
    Management-Fehler und ist gültig, wenn das bit MMFARVALID in der SCB->CFSR
    registrieren.

    Bestimmen der PC-Wert zum Zeitpunkt der Ausnahme, die Sie benötigen, zu prüfen, den stack; der Prozessor schiebt R0-R3, R12, PC und LR vor der Ausführung der Prozedur. Der stack verwendet werden kann, entweder Haupt - (wenn bit 2 von LR ist 0) oder Prozess (sonst). Siehe Seite 13 der Hinweis app für details.

    Dank Igor, wie kann ich das abrufen der PC aus dem stack?
    Sie müssen zu Holen, PSP oder MSP und bekommen ein Wort bei offset 0x18. Finden Sie ein Beispiel für die Implementierung findest du hier: embdev.net/topic/170640#1636052
    Immer noch versuchen, um dies herauszufinden. Ist dieser offset-24 bytes über die MSP?: uint32_t *pc = (uint32_t *) ((char *)_get_MSP() + 24);
    Sollte man es in assembler, der compiler könnte passen Sie die Stapel-Wert, bevor Sie Ihren code.
    Ja, ich bin zu sehen, dass. Nur die Korrektur für die offset-und immer die richtigen PC-Wert jetzt. Ich werde testen müssen, im release-Modus, um sicherzustellen, der offset ändert sich nicht. Nochmals vielen Dank!

    InformationsquelleAutor Igor Skochinsky

  2. 3

    Sollten Sie schauen in die ARM Architecture Reference Manual im Abschnitt Ausnahmen. Sie müssen sich registrieren, um es zu bekommen.

    In der Regel eine entsprechende Adresse wird in link register LR (R14), aber die genaue Bedeutung variiert je nach die Ausnahme, und es gibt unterschiedliche offsets.

    W. r.t. der Zugriff auf die User/System-Modus-register-bank, ich glaube, Sie müssen den Modus wechseln, um es aufzurufen.

    Ahh, cool! Gerade überprüft es beim Debuggen (habe keine Ahnung, wie das aufrufen einer hard fault aktuell ;p ) und in der Tat zeigt die Adresse des Anrufers. Vielen Dank!
    OK, ich sehe, es ist nicht der Anrufer, sondern der return-Adresse.
    Generiert ich den hard fault durch: *((char *)0x00) = 5;

    InformationsquelleAutor starblue

  3. 1

    Wenn eine Ausnahme Auftritt, wird der Prozessor Zustandswechsel vom aktuellen Zustand zu dem Abbruch Zustand. In der abort-Zustand der Prozessor-Schichten zu verwenden, einen neuen Satz von Registern für sp und lr (sp_abt und sp_lr beziehungsweise. Für eine data abort, die problematische Anweisung finden Sie in lr_abt + 8 für ein Präfekt über in lr_abt + 4 (gemäß dem ARMv7-Architektur Referenz-Handbuch)

    Genial, vielen Dank!
    geändert sp_abt zu lr_abt ganz böser Fehler meinerseits - ist jetzt behoben
    Dies gilt für die classic-ARM, nicht aber den Cortex-M3
    Ich denke, du meintest lr_abt-8 und lr_abt-4.

    InformationsquelleAutor doron

  4. 1

    Habe ich eine FAQ zu diesem Thema. Die Seite, auf die Links in der FAQ enthält fault handler code , erhalten den Programmzähler vom stack für Sie.

    InformationsquelleAutor Richard

  5. 0

    Ich fand eine gemeinsame Ursache für diese Probleme sind diejenigen, die 'for-Schleife' Verzögerungen. Bei Verwendung von-O3 ist Sie einfach wegoptimiert, wenn Sie sind nicht in Bezug auf volatile-Variablen. Persönlich bevorzuge ich die SysTick Ansatz.

    Danke @leppie, von ganzem Herzen Zustimmen. Keine for-Schleife Verzögerungen hier, ich, m auch mit SysTick für meinen zählen. Jedes Ding ist in einer state machine als auch, um zu vermeiden, blockiert. Ich denke, das problem würde sich im debug-Modus, wenn ich gab es genug Zeit.

    InformationsquelleAutor leppie

Schreibe einen Kommentar