Hallo, weis jemand ne möglichkeit raus zu finden, welcher unbehandelte Interrupt einen grad in den Defaulthandler befördert hat? Ich errinere mich daran, dass die Interruptnummer mit einem Offset in irgend einem Register stand. Weis jemand da mehr? Gruß
Sonke A. schrieb: > weis jemand ne möglichkeit raus zu finden, welcher unbehandelte > Interrupt einen grad in den Defaulthandler befördert hat? Gib jedem Interrupt einen eigenen Handler, dann weißt du genau welche Interruptquelle verantwortlich ist. Eventuell bringt der NVIC auch ein Register mit, indem man anhand von Flags sieht, welcher Interrupt aktiv ist. Dazu müsste man mal die Doku wälzen. Gruß Oliver
Gast
#2898150
Oliver J. schrieb: > Eventuell bringt der NVIC auch ein > Register mit, indem man anhand von Flags sieht, welcher Interrupt aktiv > ist. So ist es - das IPSR, welches das unterste Byte des xPSR ist, enthält immer die Nummer der aktuellen Exception, bzw. 0 wenn keine aktiv. Im GDB z.B. einfach "info reg" eingeben, dabei wirt das xPSR mit ausgegeben. Wenn es einer der Fault-Handler ist, kann man über das CFSR noch mehr Informationen kriegen. Das sollte an Stichworten für die Doku reichen ;-)
Gast
#2898156
>weis jemand ne möglichkeit raus zu finden, welcher unbehandelte >Interrupt einen grad in den Defaulthandler befördert hat? Interrupts einen nach dem anderen abschalten. Der letzte der übrig bleibt war der schuldige.
Sonke A. schrieb: > weis jemand ne möglichkeit raus zu finden, welcher unbehandelte > Interrupt einen grad in den Defaulthandler befördert hat? Wie kommt man zu dieser Fragestellung? Code von einem (Ex-)Kollegen übernommen?
Gast
#2899044
Roland H. schrieb: > Wie kommt man zu dieser Fragestellung? Code von einem (Ex-)Kollegen > übernommen? Indem man einen der Examplecodes oder Templates verwendet hat, welche einen Default_Handler haben, in den gesprungen wird, wenn man nicht explizit eine eigene ISR angegeben hat. Ist ja eigentlich auch schöner, als 90 leere Funktionen zu haben...
Jep genau so ist es. Sampletreiber für SD Karte genommen mit FAT verheiratet und beim lesen verschiedener Blöcke wird ein nicht behandelter Interrupt ausgelößt. Hatte zu erst den DMA im Verdacht, da ich hier aber alle Interrupts implementiert habe und keiner zuschlug meine Idee bevor ich alle 70 oder 80 Interrupts implementieren mal auf die weise raus zu finden welcher es denn ist. Habe leider keine Doku zum xpsr gefunden. Angezeigt und kennen tue ich nur das cpsr. ist das das gleiche? Zusätzlich dazu, im cpsr steht dezimal 35. jetzt habe ich Interrupts von -14 bis z.B. 67 Muss ich da jetzt 15 als Offset annehmen? Wie gesagt, habe bei st kein edoku zu den Registern gefunden.
Gast
#2899113
Sonke A. schrieb: > Habe leider keine Doku zum xpsr gefunden. ARMv7 Architecture Reference Seite 624, Kapitel B1.4.2. > Angezeigt und kennen tue ich nur das cpsr. ist das das gleiche? Keine Ahnung, das steht in meiner Doku nicht drin Sonke A. schrieb: > Zusätzlich dazu, im cpsr steht dezimal 35. jetzt habe ich Interrupts von > -14 bis z.B. 67 Muss ich da jetzt 15 als Offset annehmen? Welche Zahl im IPSR welcher Exception entspricht steht auf Seite 633, Kapitel B1.5.2 . Welche Exceptions zwischen 16 und 16+N liegen steht dann in der Doku des jeweiligen STM32.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.