Ich habe folgendes Problem: Die Funktion CNC::waitForPositionMatch() wird im Linker als Discarded markiert. Das ist auch richtig so, aber diese Funktion taucht im Disassembly beim Debuggen an der Adresse 0x0 wieder auf und zersört mir dort meinen Code, da an Adresse 0x0 eigentlich ein Handler steht. Das Symbol taucht im disassembly wieder auf, obwohl es dort eigentlich gar nicht exisiteren dürfte. Der Build Analyzer weiß auch nichts von der Funktion. Eigentlich sollte an Adresse 0x0 die ISR_TIMER_2 stehen, aber das Symbol ISR_TIMER_2 taucht dort nicht auf. Wenn ich im Disassembly nach dem Symbol ISR_TIMER_2 suche, springt er schon an die richtige Adresse, nur steht dort CNC::waitForPositionMatch. Woran kann das liegen? Ist das ein Bug? Im Speicher bei 0x08000000 (Vector Table, ist ein STM32) ist auch die richtige Sprungadresse zu ISR_TIMER_2 eingetragen (genaue Adresse 0x080000B0). Das eigentliche Problem ist jetzt allerdings, dass irgendwie eine undefined-Instruction in dem ganzen Wirrwarr mitmischt, die mich in einen Usage-Fault laufen lässt (dürfte an 0x4 sein). Wenn ihr noch mehr Infos braucht, bitte fragen. Grüße
:
Bearbeitet durch User
Leopold N. schrieb: > da an Adresse 0x0 eigentlich ein Handler steht Leopold N. schrieb: > Eigentlich sollte > an Adresse 0x0 die ISR_TIMER_2 stehen, Nö, da gehört der ISR-Vektor hin, an dessen Anfang der initiale Stack-Pointer steht, denn bei 0x0 ist der Programmspeicher abgebildet, d.h. entweder 0x08000000 für Flash oder 0x20000000 für RAM (je nach BOOT-Pins). In disassembly.PNG sieht es auch nicht so aus als würde bei 0x0 sinnvoller Code stehen. Das ist vermutlich der fehl-disassemblierte ISR-Vektor. Leopold N. schrieb: > Wenn ich im Disassembly nach dem Symbol > ISR_TIMER_2 suche, springt er schon an die richtige Adresse, nur steht > dort CNC::waitForPositionMatch. Das kann sein, macht aber nichts - der Debugger zeigt einfach den Namen des ersten Symbols an, was die Adresse hat. Wenn beide Symbole die selbe Adresse haben, was sein kann wenn das eine einen Default-Wert hat, steht da ggf. das falsche Symbol. Das ist aber nicht weiter schlimm. Leopold N. schrieb: > Das eigentliche Problem ist jetzt allerdings, dass irgendwie eine > undefined-Instruction in dem ganzen Wirrwarr mitmischt Versuchst du Adresse 0x0 auszuführen an welcher sich wie gesagt der ISR-Vektor befindet? Zeig ein minimales reproduzierbares Beispiel, mit Linker Script, Makefile & Startup-Code, sonst ist das alles nur raten.
Also: Boot Pins stehen auf Execution from Flash und Vector Table startet an 0x08000000. Mit Offset 0xB0 steht dann der Vector ISR_TIMER_2, wie in memory.png zu sehen. Anbei mal das Linker Script und der Startup-Code, Makefile ist das Standardmakefile der STM32CubeIDE für ein STM32 Projekt.
Leopold N. schrieb: > Makefile ist das > Standardmakefile der STM32CubeIDE für ein STM32 Projekt. Hab ich nicht installiert, kann ich nicht testen... Achso, du hast den ITCM an Adresse 0, dann macht das schon eher Sinn. Ich glaube dass waitForPositionMatch bei 0 angezeigt wird ist völlig egal. Prüfe mal ob der Code auch wirklich korrekt in den ITCM kopiert wird (Memory Dump von Adresse 0x0), und ob man den nicht vorher einschalten muss, und ob deine CPU (Cortex-M7?) da vielleicht noch eine "dsb" und "isb" vor dessen Ausführung und einen Cache-Flush haben möchte. Führe mal testweise eine normale Nicht-ISR-Funktion aus dem ITCM aus.
ITCM muss man nicht einschalten. Das komische ist, dass ähnlicher Code bereits vorher funktioniert hat. ISR aus dem ITCM ausführen hatte bisher problemlos geklappt. Mich verwirrt vorallem, wie eine Funktion, die in der Linker Stage eliminiert wurde, im elf-File auftauchen kann. Cache benutze ich momentan noch nicht. DSB oder ISB wird nicht benötigt. Nicht-ISR Funktionen führe ich massenweise aus dem ITCM aus. Funktionieren alle tadellos. Die gesamte .code_sram Section wird aus dem ITCM ausgeführt und passt problemlos. Ich werde trotzdem gleich nochmal checken, ob der Code richtig kopiert wird. Aber selbst wenn nicht, gibt es dann immernoch ein Problem mit der Debug Information.
Hier nochmal der Memory vor und nach dem Kopieren des Codes aus dem Flash. Sieht passend aus.
Leopold N. schrieb: > Mich verwirrt vorallem, wie eine Funktion, die in der Linker Stage > eliminiert wurde, im elf-File auftauchen kann. Sicher dass sie da überhaupt auftaucht, und nicht einfach nur das Symbol die Adresse 0 hat und da noch angezeigt wird, während da aber tatsächlich der gewünschte Code der ISR ist? Die Debugging-Tools sind nicht wirklich darauf ausgelegt, dass an 0x0 valider Code steht. Leopold N. schrieb: > DSB oder ISB wird nicht benötigt. Das braucht man auch ohne Cache. Die Prozessor-Pipeline kann man schließlich nicht abschalten. Leopold N. schrieb: > gibt es dann immernoch ein Problem mit der Debug > Information. Was für eins? Leopold N. schrieb: > Hier nochmal der Memory vor und nach dem Kopieren des Codes aus > dem > Flash. > Sieht passend aus. Zeig mal die Ausgabe von "arm-none-eabi-objdump -s -d -j .code_sram", dann kann man das vergleichen. Und zeig den Code der ISR. Steppe im Single-Instruction-Modus durch den Code und finde die Stelle, an der es crasht. Es ist sehr verdächtig, dass in disassembly.PNG kaputter Assembler-Code zu sehen ist.
Bin dem Problem schon auf der Spur...typisches Nullpointer Problem...habe den Code gefunden, der zwischen dem Startup und der ISR das erste Word an Adresse 0x0 durch einen Nullpointer überschreibt...eigentlich habe ich per MPU nur privilegierte Software den Zugriff auf 0x0 erlaubt, aber es ist leider auch privilegierter Code, der da Mist baut. Ist durch eine Änderung in meinem Betriebssystem passiert, bei der ich wohl vergessen habe, auch entsprechende andere Stellen im Code anzupassen. Damit dürfte das Problem gegessen sein. Dankeschön
:
Bearbeitet durch User
Leopold N. schrieb: > eigentlich habe ich per MPU nur privilegierte Software > den Zugriff auf 0x0 erlaubt, Erlaube am Besten überhaupt keiner Software den Schreibzugriff darauf, nachdem der Startupcode das schon initialisiert hat. Na dann hat's sich ja geklärt :)
Programmierer schrieb: > Leopold N. schrieb: >> eigentlich habe ich per MPU nur privilegierte Software >> den Zugriff auf 0x0 erlaubt, > > Erlaube am Besten überhaupt keiner Software den Schreibzugriff darauf, > nachdem der Startupcode das schon initialisiert hat. Na dann hat's sich > ja geklärt :) Stimmt eigentlich...gar keine so schlechte idee, hätt ich auch selbst drauf kommen können :) Vielen Dank für deine Bemühungen und schnellen Antworten.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.