GDB - ARM, Debug mit Offset

[Vincent H. (vinci)]

Grüß euch

Besteht irgendwie die Möglichkeit via GDB ein Programm auf einem Cortex 
M4 von einem Offset weglaufen zu lassen? Wie verhält sich der Debugger, 
wenn die ersten beiden Einträge des Vector Tables (Stack & PC) zur 
Resetzeit schlichtweg 0xFF... sind?

Ich hab da in erster Linie an irgendein Startup-Skript gedacht, dass von 
einem definiterten Offset den tatsächlichen Vektor Table lädt und SP/PC 
entsprechend setzt.

Erste kurze Versuche mit Eclipse und dem GNU ARM Plugin haben mich 
leider überhaupt nicht weitergeführt.


Anwendungsfall ist, wie könnte es anders sein, ein Bootloader, den ich 
gerne gleich in der Hauptanwendung berücksichtigen würde, ohne extra ein 
eigenes Linker Skript dafür zu erstellen. Alternativ würde ich dann wohl 
das .o-File des Bootloaders direkt einbinden... so richtig "schön" ist 
die Lösung aber irgendwie auch nicht.


lg

[Jim M. (turboj)]

Vincent H. schrieb:
> Wie verhält sich der Debugger,
> wenn die ersten beiden Einträge des Vector Tables (Stack & PC) zur
> Resetzeit schlichtweg 0xFF... sind?

Die CPU geht (über Hardfault) in den Lockup. Den kann ein Debugger aber 
aufheben.

Funktionieren würde es nur, wenn SP und PC explizit vom Debugger 
initialisiert werden. Könnte sein dass man das bei GDB manuell machen 
muss.

Vincent H. schrieb:
> Ich hab da in erster Linie an irgendein Startup-Skript gedacht, dass von
> einem definiterten Offset den tatsächlichen Vektor Table lädt und SP/PC
> entsprechend setzt.

BTDT. Funktioniert wenn man auch an VTOR gedacht hat. Vorsicht: Manche 
Debugger Setups löschen den Chip komplett vorm flashen.

[Ruediger A. (Firma: keine) (rac)]

Ich benutze WinIdea, da kannst Du einen Startup PC override definieren. 
Ist aber natürlich auch etwas krümelig, ausser dieser Startup PC ist im 
linker script so festgenagelt, dass er sich niemals ändert. Der SP ist 
natürlich nicht so wild, weil man den ja bis zum ersten Gebrauch nach 
Belieben im Reset Vector Code umbiegen kann (machen ja auch viele 
Startupcodesequenzen schon von Haus aus).

Was mich allerdings wundert ist wie Du das Ganze aufsetzen willst. Der 
Cortex Kern startet grundsätzlich und ausnahmslos von den Vektoren an 
Adresse 0 (wobei natürlich, wie Du sicher weisst, die 0 bei manchen PODs 
von externer Beschaltung abhängig auf Andere Adressbereiche gespiegelt 
werden kann). Wenn ich Dich richtig verstehe, willst Du deine 
Applikation so bauen, dass es für sie so aussieht, als würde beim Reset 
in sie, nicht in den Bootloader, booten, selbst wenn gerade kein 
Bootloader dazwischen ist? Meine Lösung wäre in dem Fall eher, den 
Bootloader als statisches Image an die richtige Stelle zu legen (da ist 
die Boot IVT ja auch schon an der richtigen Adresse) und an den 
Programmeinstiegspunkt einen harten Breakpoint zu setzen. Für einen 
einigermassen realistischen Betrieb willst Du ja schon einen Bootloader 
resident haben (z.B: zum ISR forwarding).

[Vincent H. (vinci)]

Danke für die Vorschläge, letztendlich kam aber "Atollic to the rescue" 
;)


S.19 des angehängten Dokuments brachte die Erlösung. Ich kannte den GDB 
nicht genug, um zu wissen, dass man damit auch Adressen wie im 
Screenshot zu sehen dereferenzieren kann...

Nun wird beim Start der Debug-Session PC und SP von der richtigen 
Adresse geladen und auch gleich gesetzt. Anschließend musste man in 
Eclipse nur noch das Executeable "refreshen", weil sonst die Symbole aus 
irgendeinem Grund nicht gefunden werden können...

[tom (Gast)]

Hallo Vincent,

Ich flashe für so etwas eine minimal-app unten in den Flash, die die zu 
debuggende applikation anspringt, letztlich der jump des bootloaders in 
die applikation ohne etwas dazu. Das funzt mit CooCox prima, sollte also 
mit jedem gdb basierten frontend auch tun. refresh wg. symbolen muss ich 
nicht machen.

gruss, Tom.