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.
Siehe BusFault Status Register (BFSR) zur Ursache des BusFault.
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.