Debugging Issues with GDB and OpenOCD

Development Boards MicroMod
1

Hi,

I’m having some difficulty getting a certain breakpoint to work with GDB and OpenOCD. I have a target reset and halted, I’ve set a breakpoint at main “break main” using GDB, and for some reason GDB is unable to properly break at the breakpoint; communication is lost with OpenOCD instead.

The program I’m trying to debug is the blinking LED example by Jim Lynch for the Olimex LPC-H2148 board.

The GDB information is below. I edited the output a little bit to remove some escape sequences that were generating errors in the preview: …[forward slash]

It has a startup script that connects to the openOCD GDB server via: target extended-remote localhost:3333

GNU gdb 6.8.50.20080308-cvs
Copyright (C) 2008 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-pc-mingw32 --target=arm-elf"...
0x00000190 in main () at main.c:45
45              for (j = 0; j < 500000; j++ ){
(gdb) monitor reset halt
JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
(gdb) monitor poll
target state: halted
target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
(gdb) set $pc=0
(gdb) where
#0  0x00000000 in _vectors ()
(gdb) break main
Breakpoint 1 at 0xe8: file main.c, line 29.
(gdb) continue
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
Remote communication error: No error.
(gdb)

Here is debug information from OpenOCD :

Open On-Chip Debugger 1.0 (2008-07-14-22:18) svn:807
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
Info:    options.c:50 configuration_output_handler(): jtag_speed: 5, 5
Info:    options.c:50 configuration_output_handler(): Open On-Chip Debugger 1.0 (2008-07-14-22:18) svn:807
Info:    jtag.c:1395 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x
4)
Warning: tcl_server.c:179 tcl_init(): no tcl port specified, using default port 6666
Info:    jtag.c:1395 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x
4)
Info:    server.c:78 add_connection(): accepting 'gdb' connection from 0
Warning: gdb_server.c:416 gdb_get_packet_inner(): acknowledgment received, but no packet pending
Info:    jtag.c:1395 jtag_examine_chain(): JTAG device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x
4)
Warning: gdb_server.c:347 gdb_put_packet_inner(): negative reply, retrying
Warning: gdb_server.c:416 gdb_get_packet_inner(): acknowledgment received, but no packet pending
User:    target.c:974 target_arch_state(): target state: halted
User:    armv4_5.c:307 armv4_5_arch_state(): target halted in ARM state due to debug request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
Error:   target.c:292 target_resume(): timeout waiting for target resume
Error:   gdb_server.c:371 gdb_put_packet_inner(): unknown character 0x24 in reply, dropping connection
Warning: gdb_server.c:426 gdb_get_packet_inner(): ignoring character 0x67
Warning: gdb_server.c:426 gdb_get_packet_inner(): ignoring character 0x23
Warning: gdb_server.c:426 gdb_get_packet_inner(): ignoring character 0x36
Warning: gdb_server.c:426 gdb_get_packet_inner(): ignoring character 0x37
Info:    server.c:388 server_loop(): dropped 'gdb' connection

Here is the OpenOCD configuration (without comments):

telnet_port 4444
gdb_port 3333
gdb_memory_map enable
gdb_flash_program enable
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG TINY A"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0004
jtag_speed 5
jtag_nsrst_delay 500
jtag_ntrst_delay 500
reset_config trst_and_srst separate
jtag_device 4 0x1 0xf 0xe
daemon_startup reset
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
run_and_halt_time 0 30
working_area 0 0x40000000 0x80000 nobackup
flash bank lpc2000 0x0 0x7D000 0 0 0 lpc2000_v2 12000 calc_checksum

The breakpoint itself is actually hit by OpenOCD. If I reconnect to the OpenOCD GDB server and do a monitor poll command it shows the target stopped at the first line of code inside main(). It’s just GDB doesn’t seem to understand that the breakpoint has been hit in this one circumstance.

I don’t know if this is GDB problem, an OpenOCD problem, a problem with my configuration or a combination of the above.

Note that after this point in time if I set breakpoints later on in the code, I’m able to hit them and step through just fine. There is a problem with empty for loops which I was able to workaround by inserting a dummy instruction inside the for loop.

My questions are:

  • 1. Does anyone have ideas about what could be causing the inability to properly hit the first breakpoint in main()?
    1. Does anyone have better workarounds for stepping empty for loops? I’ve seen other posts where people have had issues stepping through empty for loops, but those posts were from a couple of years ago.

    Thanks!

    • 2

    update to the latest svn - the resume behaviour has been fixed.

    Cheers

    Spen

    3

    Thanks Spen!