STM32 Debugging mit Open-OCD/Eclipse

[Bernd G. (bege)]

Hallo,

ich habe folgendes Problem beim Debuggen mit Eclipse/Gdb/Open-OCD und 
meinem ST32F3 Discovery Board.

Im Flash habe ich eine Library mit diversen Funktionen. Die 
Startadressen der Funktionen sind bekannt, die Funktionen sind getestet.

Meine Entwicklungsumgebung ist so aufgebaut, dass das Executable ins RAM 
gelinkt wird. Dabei werden die Lib-Funktionen im Flash über 
Funktionspointer angesprungen.

Wenn ich eine Debug-Session mit meiner Applikation (im RAM) starte, 
funktioniert das Debuggen solange, bis ich eine Funktion aus der Lib 
aufrufen will. Sobald ich die Funktion im Flash anspringen will, landet 
der Debugger in einer Exception (WWDG_IRQHandler).

Ich habe einen Break-Point auf den Funktionsaufruf gesetzt. Der Aufruf 
sieht OK aus, die Stelle an die gesprungen werden soll auch.

Der Assembler-Code sieht so aus:

0x2000389c:   movw r3, #32244 ; 0x7df4
0x200038a0:   movt r3, #8192  ; 0x2000   <- Adresse der Funktion holen
0x200038a4:   ldr r3, [r3, #0]
0x200038a6:   ldr r3, [r3, #8]           <- Adresse der Funktion nach R3
0x200038a8:   movw r0, #31324 ; 0x7a5c   <- Funktionsparameter nach R0
0x200038ac:   movt r0, #8192  ; 0x2000
0x200038b0:   blx r3                     <- Funktion aufrufen

Führe ich den blx aus, lande ich hier (der Fash-Code ist OK, er wird 
aber falsch dekodiert):

0x08001428:    ; <UNDEFINED> instruction: 0x4604b5f8
0x0800142c:   cmnlt r8, r0, lsr #16
0x08001430:   tstle r9, r11, lsl r8
0x08001434:   strbcs r4, [r0], -r7, lsl #26
0x08001438:   stmdavc r0!, {r1, r2, r3, r5, r8, r10, pc}^

Hier das List-File:

 8001428:  b5f8        push  {r3, r4, r5, r6, r7, lr}
 800142a:  4604        mov  r4, r0
 800142c:  7820        ldrb  r0, [r4, #0]
 800142e:  b178        cbz  r0, 8001450 <LCD_Send_String+0x28>
 ...

Was muß ich tun, damit der Debugger den Code ab Adresse 0x8001428 sauber 
erkennt und ausführt?

Bernd

[Jim M. (turboj)]

Was für ein Wert steht in R3, wenn die BLX R3 Instruktion ausgeführt 
wird? Ist das Thumb Bit gesetzt?

[Bernd G. (bege)]

In R3 steht 0x08001428. :-(

Der Tip war schon mal gut ;-)

Ok, ich hab's geändert, jetzt steht zwar 0x08001429 drin und der Code 
läuft durch. Trotzdem werden die Befehle vom Debugger falsch dekodiert 
(wie oben beschrieben).

[Alex E. (tecnologic)]

Hi Bernd,

kann der Debugger nur den source der Lib nicht anzeigen? wenn ja hast du 
die symbole von dem Lib geladen? (gdb cmd: file ./blalib.elf)

MfG

Tec

[bege (Gast)]

>kann der Debugger nur den source der Lib nicht anzeigen?
Das *.els der Lib sind nicht geladen. Daher auch keine Symbole.
Das ist aber auch logisch und Ok.

Was mich allerdings etwas stört ist, dass der Debugger die 
Assemblerbefehle der Lib nicht richtig anzeigt. Kann man ihm irgendwie 
sagen, dass von Adresse_x bis Aresse_y auch ausführbarer Code (mit 
Thumb-Befehlen) zu finden ist?
Wenn ja wie ?

Ich hatte ja schon geschrieben was passiert:
Debugger-Anzeige:

0x08001428:    ; <UNDEFINED> instruction: 0x4604b5f8
0x0800142c:   cmnlt r8, r0, lsr #16
0x08001430:   tstle r9, r11, lsl r8
0x08001434:   strbcs r4, [r0], -r7, lsl #26
0x08001438:   stmdavc r0!, {r1, r2, r3, r5, r8, r10, pc}^

List-File:

 8001428:  b5f8        push  {r3, r4, r5, r6, r7, lr}
 800142a:  4604        mov  r4, r0
 800142c:  7820        ldrb  r0, [r4, #0]
 800142e:  b178        cbz  r0, 8001450 <LCD_Send_String+0x28>

Ich hätte erwartet, dass der Debugger die Befehle genau so anzeigt wie 
sie im List-File stehen, egal ob ein *.elf geladen ist oder nicht.

Bernd