I am presently having difficulties getting breakpoints to work with
openOCD 0.10, Eclipse Ganymede, GDB 6.8, ARM-USB-TINY.
All trying to debug a Eagle 100 board with LM3S6918.
I also have a post at:
https://lists.berlios.de/pipermail/open … 08418.html
If I (or you the reader) find a solution, I will post to both.
Thanks,
Joe
I am still not there yet. The folks a openOCD development list had some comments:
(a) Try your program in RAM, see if breakpoints work there, this rules out RAM vrs FLASH breakpoint problems.
(b) Where are the breakpoints being placed? Flash or RAM?
(c) GDB often tries to keep track of your earlier breakpoints - how many do you have active? With Insight (GDB-TK) one often must cleanup and delete the cached list of break points when code changes, otherwise they get put in rather strange places.
(d) Enable the “debug log level 3” - what does the log tell you when you set a break point and run (read the openocd manual about this)
(e) Where did you get OpenOCD from? Did you build it, or did you download a pre-built version?
I am still pursuing help in that arena,
To stay tuned see:
The saga continues:
https://lists.berlios.de/pipermail/open … 08821.html
More details, my openOCD config files , and gdb commands are there.
Here are my openOCD configuration files:
Continued call for help !
It still seems that these are hard to read on the other
posting, I will just inline them here
####Eagle100_jtag_tiny-setup.cfg===========================================
interface ft2232
ft2232_device_desc “Olimex OpenOCD JTAG TINY A”
ft2232_layout olimex-jtag
#------------------------------------------------------------------
set BSTAPID 0x16410041
#------------------------------------------------------------------
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME lm3s6918
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x3ba00477
}
jtag_khz 500
jtag_nsrst_delay 100
jtag_ntrst_delay 100
#LM3S6918 Evaluation Board has only srst
reset_config srst_only
#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0xf -expected-id $_CPUTAPID
#daemon startup reset
#this config option has been removed, simply adding init' and reset halt’ to the end
#of your config script will give the same behaviour as using `daemon_startup reset’
#and `target cortex_m3 little reset_halt 0’.
set _TARGETNAME [format “%s.cpu” $_CHIPNAME]
target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position $_TARGETNAME -variant lm3s
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x20000000 -work-area-size 0x4000 -work-area-backup 0
#flash configuration
flash bank stellaris 0 0 0 0 0
#recommded by Duane Ellis of openOCD
#This tells openocd to inform GDB where ‘flash lives’ - thus GDB will attempt to#use hardware breakpoints.
#----
gdb_memory_map enable
#----
####Eagle100_jtag_tiny-setup.cfg===========================================
Then the following of these is sent next to openOCD:
telnet_port 4444
gdb_port 3333
init
reset
Or
#define our ports
telnet_port 4444
gdb_port 3333
tcl_port 6666
echo “before init”
init
halt
sleep 200
wait_halt
flash probe 0
flash erase_check 0
#flash protect 0 8 255 off
flash erase_sector 0 0 255
sleep 200
flash erase_check 0
reset run
shutdown
If the chip was already programmed:
openocd -d 3 -f Eagle100_jtag_tiny-setup.cfg -f DebugPgm.cfg -l openocdLogj26.txt
To see if gdb could directly program a blank chip - this did work.
openocd -d 3 -f Eagle100_jtag_tiny-setup.cfg -f ErasePgm.cfg -l openocdLogErase.txt
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
Next
I executed the following gdb commands from dos window
=====
Specify the ELF file…
=====
(gdb) file blinky.out.
=====
Specify the target
=====
(gdb) target remote localhost:3333
=====
Tell openocd to HALT the target
=====
(gdb) mon halt
=====
Tell openocd to RESET the target.
=====
(gdb) mon reset
=====
And i tell it to halt again…
=====
(gdb) mon halt
=====
Load my program - this actually programs the flash
=====
(gdb) load
=====
Set a breakpoint at “blinky.c line24”
=====
(gdb) break blinky.c:24
=====
Tell GDB to continue - see the NOTE from GDB…
=====
(gdb) cont
=====
I did not hit my breakpoint…
=====
It required using contorl C to stop running.
=====
Does not work yet, please help…
=====
… and got stuck with no
working breakpoints as described.
Joe
To All,
It turns out my big breakpoint problem was due to my using a
makedefs file that configured the gnu compiler to optimize for size.
Apparently the debugger needs to have NO optimizations on to work properly.
Well I think I will rember this solution for a while !
DEBUG=-g
Now my Eclipse environment appears to be working ok too.
Best regards, 
Joe
It may also be that after the reset the CPU has run past the breakpoint already by the time it’s reinstated.