Ich arbeite an einer Reihe von Debugging-Tools für einige interne Cortex-M4-Kerne. Ich erstelle eingebettete (keine OS) ELF Bilder mit einer gcc/binutils Toolchain und simuliere sie mit einer modifizierten Version von QEMU. Ich erstelle die Interrupt-Vektortabellen am Anfang (d. H. 0) meiner Bilder und initialisiere den Stapelzeiger und die Startadresse (d. H. Die Adresse der Hauptadresse) korrekt.Soft-Reset auf einem Cortex-M mit GDB
Die Zielprogramme werden wie erwartet ausgeführt und die Debug-Tools, die unter Verwendung des entfernten GDB-Protokolls erstellt wurden, funktionieren ordnungsgemäß.
Was ich gerade versuche zu verstehen ist, wie man einen Soft-Reset von GDB initiiert. Das heißt, veranlassen, dass das Zielprogramm neu initialisiert wird, wobei der Stapelzeiger auf den Anfangswert in der Vektortabelle zurückgesetzt wird, und der PC zurück an der Startadresse.
Ich habe mir bereits gezeigt, dass die Aktion des Festlegens des PC-Werts auf 0 und das Ausführen des Kerns nicht geeignet ist, und das Ergebnis war, dass mein "UsageFault" -Ausnahmehandler aufgerufen wurde. (Ich gehe davon aus, dass der Kern im falschen Modus ist, um diese Art von Aktion auszuführen).
Gibt es eine Technik, d. H. Durch Register schreibt mit GDB Remote-Protokoll, dass ich den simulierten Kern soft-reset kann, das heißt, ohne die QEMU-Sitzung aus- und wieder einschalten zu müssen?
Adresse 0 ist der anfängliche Stapelzeiger. –
Korrigieren. Direkter Zugriff auf den SP aus einer Anwendung wird jedoch von Cortex-M im Thumb-Modus verhindert. Da die Neuinitialisierung des SP eine Anforderung eines SW-Reset ist, ist eine andere Methode erforderlich. Viks Antwort unten scheint nahe bei dem zu sein, was benötigt wird, ich muss nur genau debuggen, was eigentlich ist, wenn ich QEMU den Speicher über GDB schreibe. –