Cortex-M3 - GDB - Breakpoints werden nicht erkannt

[Lasse S. (cowz)]

Hallo,

wie in den anderen Beitragen auch schon zu lesen, beschäftige ich mich 
seit ein paar Tagen mit dem Cortex-M3, genauer einem STM32F103RB auf dem 
Olimex STM32-H103 zusammen mit dem Segger J-Link EDU.

Nun versuche ich mittels GDB zu debuggen (und zwar noch direkt in der 
Konsole). Allerdings ignoriert er einfach meine Breakpoints. Er läuft 
einfach die Main immer wieder durch (die LED blinkt).

Könnt ihr mir sagen warum?

Folgendes hab ich in meine Konsole getippt, der untere Teil ist im Log 
vom Segger GDB-Server.


Gruß
Lasse

PS: Ja, das war den Tag über noch in GCC, aber ich hab's mal hierher 
"verschoben", da das zwar die Binutils, aber nicht den GCC ansich 
betrifft. Und im GCC antwortet keiner, vielleicht liegt's ja am falschen 
Forum.. hoff

C:\Projektpfad\Release>arm-none-eabi-gdb ausgabe.elf
GNU gdb (Sourcery G++ Lite 2009q3-68) 6.8.50.20090630-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-mingw32 --target=arm-none-eabi".
For bug reporting instructions, please see:
<https://support.codesourcery.com/GNUToolchain/>...
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0x00000000 in ?? ()
(gdb) monitor speed auto
Select auto JTAG speed (1000 kHz)
(gdb) monitor flash device=stm32f103rb
Select flash device: stm32f103rb
(gdb) monitor flash breakpoints = 1
Flash breakpoints enabled
(gdb) monitor flash download = 1
Flash download enabled
(gdb) load
Loading section .text, size 0x4148 lma 0x8000000
Loading section .data, size 0x14 lma 0x8004148
Start address 0x8000000, load size 16732
Transfer rate: 466 KB/sec, 2788 bytes/write.
(gdb) monitor reg r13 = (0x00000000)
Writing register (SP = 0x00500020)
(gdb) monitor reg pc = (0x00000004)
Writing register (PC = 0x6D020008)
(gdb) monitor reset
Resetting target
(gdb) break main
Breakpoint 1 at 0x80001ca: file ../main.c, line 54.
(gdb) continue
Continuing.

Im GDB-Server von JLink steht dann:

Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0x00500020)
Select auto JTAG speed (1000 kHz)
Select flash device: stm32f103rb
Flash breakpoints enabled
Flash download enabled
Downloading 4032 bytes @ address 0x08000000
Downloading 4016 bytes @ address 0x08000FC0
Downloading 4048 bytes @ address 0x08001F70
Downloading 3984 bytes @ address 0x08002F40
Downloading 632 bytes @ address 0x08003ED0
Downloading 20 bytes @ address 0x08004148
Writing register (PC = 0x00000008)
Writing register (SP = 0x00500020)
Writing register (PC = 0x6D020008)
Resetting target
Read 2 bytes @ address 0x080001CA (Data = 0x0121)
Setting breakpoint @ address 0x080001CA, Size = 2, BPHandle = 0x0009
Starting target CPU...

[Plan (Gast)]

Wiso zu Fuß und nicht mit z.B. Eclipse?
Ich nutze Eclipse+Coudesourcery+OpenOCD+Olimex ARM-USB-OCD+Yagarto 
Tools+GDB Hardware Debuggung PlugIn

Da Klicke ich im Code an und hab einen Breakpoint und der tut.

[Lasse S. (cowz)]

Weil ich unter Eclipse auch Probleme habe und außerdem gerne das von 
Grund auf verstehen möchte :)

[Plan (Gast)]

Ich hatte auch mal den "Segger J-Link". Aber irgendwie gabs da immer 
kleine "Hänger". Ist schon eine weile her. Ich wollte eigentlich mit SW 
(SingleWire) debuggen, aber das hat der Segger GDB Server nicht 
unterstützt.

Mit dieser HW und OpenOCD bin ich sehr zufrieden.
Martin Thomas hat in einem Thread auch mal ein komplettes Eclipse 
Projekt für den STM32 gepostet.

Liest Du hier:
Beitrag "Re: Diskussionsrunde: Opensource Entwicklungstools für STM32"

Und hier das Projekt:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_stm32

[Lasse S. (cowz)]

Das hat doch nichts mit meinem Problem zu tun, oder? ;)

[Plan (Gast)]

Nun ja, das Demo-Projekt von siwawi kann man ja mal laden und mit 
Eclipse öffnen und die GDB Einstellungen an schauen.
Schaden tut es jedenfalls nicht. Vieleicht ist da der wichtige Hinweis 
versteckt.

Vieleicht ist das ja auch der wichtige GDB-Befehl:
set mem inaccessible-by-default off

In der Doku vom Segger GDB Server stehen alle Kommandos die gehen. Über 
den GDB kann man mit "monitor" den Befehl zum GDB Server schicken.

[Lasse S. (cowz)]

Hi,

danke :D

Hätte es nicht gedacht, aber es stand wirklich was drin, was mir gefehlt 
hat.

Der Befehl

monitor endian little

fehlte.

Der steht aber so auch nicht in der Segger-Hilfe.

Den Befehl

set mem inaccessible-by-default off

brauche ich (noch?) nicht. Werde mich aber mal schlau machen, was der 
bewirkt und warum ich den vielleicht doch lieber auch nutzen sollte :)


Vielen Dank also für den Richtungsstupser, jetzt kann's weitergehen :)

Gruß
Lasse

[Plan (Gast)]

Gern geschehen...