Beim Debuggen eines Assemblerprogramms eines STM32F407 passiert es, daß
nach Durchlaufen einer gewissen Initialisierungsphase, in der ich schon
mittels Nachrichten in der SWV ITM Konsole den Programmverlauf verfolgen
kann, daß es einen BUSFAULT (Exception Code 5) gibt. Das passiert genau
in dem Moment, wo ich Interrupts einschalte (cpsie i). Die Instruktion
nach dem cpsie ist ein "b next". Führe ich die als nächstes nach dem
cpsie aus, so gibt es eine Exception 5 (Busfault).
Der SP hat dann leider einen Wert, der keine gültige Adresse darstellt
(Zahl 00000007).
Meine Frage jetzt: Wie könnte ich feststellen, welcher Interrupt u.U.
bereits in dem Moment anliegt, da ich die Interrupts enable?
Anm.: Ich habe IWDG im STM32CubeIDE während des Debuggens abgeschaltet.
Was das für den Moment bedeutet, wo das Programm läuft (und wenn es nur
eine Instruktion ist), weiß ich nicht genau. Kann also nicht genau
sagen, ob des der Watchdog ist, der mir da hineinhagelt oder etwas
anderes. Das würde ich eben gerne feststellen. Auf dem Systick-Vektor
passiert auch nichts.
Christoph K. schrieb:> Meine Frage jetzt: Wie könnte ich feststellen, welcher Interrupt u.U.> bereits in dem Moment anliegt, da ich die Interrupts enable?
In den Registern des NVIC nachsehen.
Christoph K. schrieb:> Kann also nicht genau sagen, ob des der Watchdog ist,> der mir da hineinhagelt oder etwas anderes.
Der IWDG kann keinen Interrupt auslösen, nur einen Reset. Nur der WWDG
hat ein Interrupt Enable und einen eigenen Vector.
> BUSFAULT...genau in dem Moment, wo ich Interrupts einschalte (cpsie i).
Die Interrupts sind nach einem Reset automatisch eingeschaltet. Wenn du
sie nicht selbst ausschaltest, kann cpsie eigentlich nichts bewirken.
Noch eine doofe Idee: ist der Stackpointer (MSP) kurz vor dem cpsie
(noch) richtig intialisiert?
Bauform B. schrieb:> Christoph K. schrieb:>> Kann also nicht genau sagen, ob des der Watchdog ist,>> der mir da hineinhagelt oder etwas anderes.>> Der IWDG kann keinen Interrupt auslösen, nur einen Reset. Nur der WWDG> hat ein Interrupt Enable und einen eigenen Vector.>>> BUSFAULT...genau in dem Moment, wo ich Interrupts einschalte (cpsie i).>> Die Interrupts sind nach einem Reset automatisch eingeschaltet. Wenn du> sie nicht selbst ausschaltest, kann cpsie eigentlich nichts bewirken.>> Noch eine doofe Idee: ist der Stackpointer (MSP) kurz vor dem cpsie> (noch) richtig intialisiert?
OK, hatte übersehen, daß gleich zu Beginn des Programms ein cpsid i
steht.
Ja. SP zeigt auf gültiges RAM.
Die Register des NVIC sind alle 0:
x/160 0xe000e100
0xe000e100: 0x00000000 0x00000000 0x00000000 0x00000000
0xe000e110: 0x00000000 0x00000000 0x00000000 0x00000000
...
0xe000e350: 0x00000000 0x00000000 0x00000000 0x00000000
0xe000e360: 0x00000000 0x00000000 0x00000000 0x00000000
0xe000e370: 0x00000000 0x00000000 0x00000000 0x00000000
und:
x 0xe000ed04
0xe000ed04: 0x00005000 (SCB_ICSR)
Christoph K. schrieb:> gleich zu Beginn des Programms ein cpsid i> Die Register des NVIC sind alle 0:> 0xe000ed04: 0x00005000 (SCB_ICSR)
...bis auf den BUSFAULT, der hier pending ist. Wenn das der Zustand kurz
vor dem cpsie ist, kann der BUSFAULT ja irgendwann zwischen dem cpsid am
Anfang und dem cpsie passiert sein. cpsie erlaubt ihm dann (viel zu
spät), aktiv zu werden.
Eine Daumenregler: zwischen cpsid und cpsie sollten immer nur eine
Handvoll Befehle stehen und kein Sprung und kein Unterprogrammaufruf.
Bauform B. schrieb:> Christoph K. schrieb:>> gleich zu Beginn des Programms ein cpsid i>> Die Register des NVIC sind alle 0:>> 0xe000ed04: 0x00005000 (SCB_ICSR)>> ...bis auf den BUSFAULT, der hier pending ist. Wenn das der Zustand kurz
Aus dem SCB_ICSR (0x00005000) bits 12-15
> vor dem cpsie ist, kann der BUSFAULT ja irgendwann zwischen dem cpsid am> Anfang und dem cpsie passiert sein. cpsie erlaubt ihm dann (viel zu> spät), aktiv zu werden.>> Eine Daumenregler: zwischen cpsid und cpsie sollten immer nur eine> Handvoll Befehle stehen und kein Sprung und kein Unterprogrammaufruf.
Ich kann jetzt nur mal versuchen, den cpsie i vorzuverlegen, um an die
Stelle des Busfaults heranzukommen. Danke erst mal für die Tipps.
Christoph K. schrieb:> Ich kann jetzt nur mal versuchen, den cpsie i vorzuverlegen, um an die> Stelle des Busfaults heranzukommen.
Ja, aber? Das ist doch der bessere Plan:
(prx) A. K. schrieb:> Siehe BusFault Status Register (BFSR) zur Ursache des BusFault.
Bei manchen Fehlern steht direkt daneben im BFAR die Adresse des
Fehlers.
Bauform B. schrieb:> Christoph K. schrieb:>> Ich kann jetzt nur mal versuchen, den cpsie i vorzuverlegen, um an die>> Stelle des Busfaults heranzukommen.>> Ja, aber? Das ist doch der bessere Plan:>> (prx) A. K. schrieb:>> Siehe BusFault Status Register (BFSR) zur Ursache des BusFault.>
Dort steht eine 0x04
x/b 0xe000ed29
0xe000ed29: 0x04
(IMPRECISERR)
> Bei manchen Fehlern steht direkt daneben im BFAR die Adresse des> Fehlers.
Weiß nicht, ob man das sinnvoll nennen kann:
x 0xe000ed38
0xe000ed38: 0xf8
