command line gdb debugging symbols/stack trace

[Eliot Stock]

Using the pure-gcc makefiles, at present I only see this for a stack trace in the command line gdb client:

(gdb) bt
#0  0xfffffffe in ?? ()
#1  <signal handler called>
#2  0x00000000 in ?? ()

This is weird because I do have symbols:

(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00017512 in main at ../main.c:100
2       breakpoint     keep y   0x00016c92 in gsm_uart_connect at ../gsm_ublox_sara.c:239

I'm using -ggdb in my CLFAGS:

CFLAGS += -DDEBUG -ggdb -O0

but have also tried with -g3:

CFLAGS += -DDEBUG -g3 -O0

I start the gdb server with:

JLinkGDBServer -if swd -device nrf51822 -speed 1000 -port 2331

and the client with:

/Users/Eliot/dev/gcc-arm-none-eabi-4_8-2013q4/bin/arm-none-eabi-gdb _build/device-nordic_s110.elf

My .gdbinit is just the one generated by the makefiles:

target remote localhost:2331
break main

(As an aside, it would be helpful to have a value for TERMINAL in the Makefiles for Mac so that I can simply run 'make startdebug', but I haven't been able to find one that works.)

[Ole Morten]

The pure-gcc makefiles by default doesn't currently automatically load the binary and reset the chip, and if the flash contents isn't according to what GDB expects, you'll often see this 0xFFFFFFFE address.

If you always want to do such load before you start debug, you can add the command load and mon reset to the gdbinit like this:

target remote localhost:2331
load
mon reset
break main

I'll consider changing this upstream as well, but the default behavior is useful if you want to connect to a running target... Thinking about it a second time however, the suggestion above is perhaps what's best for the 90 % use case, so it might make sense to change it.

[Eliot Stock]

Much better, thank you!

[asifhn]

I get the same problem as originally stated. And doing a "load" in gdb after "target remote ..." causes error:

(gdb) load
Loading section .text, size 0xa9d7 lma 0x16000
Loading section .ARM.exidx, size 0x8 lma 0x209d8
Loading section .data, size 0x6c lma 0x209e0
Error finishing flash operation

For whatever reason I cannot continue after I do the gdb "load". I have to re-program the nordic flash to be able to do a gdb continue. Does gdb "load" corrupt the nordic flash? I wonder!

By-the-way, I use openocd as my gdb server. I think this has something to do with sigint, but I am not sure.

[Eliot Stock]

This is not an answer. I'd post it as a new question and link back to this one if you want an answer to it.

[asifhn]

I get the same problem as originally stated. And doing a "load" in gdb after "target remote ..." causes error:

(gdb) load
Loading section .text, size 0xa9d7 lma 0x16000
Loading section .ARM.exidx, size 0x8 lma 0x209d8
Loading section .data, size 0x6c lma 0x209e0
Error finishing flash operation

For whatever reason I cannot continue after I do the gdb "load". I have to re-program the nordic flash to be able to do a gdb continue. Does gdb "load" corrupt the nordic flash? I wonder!

By-the-way, I use openocd as my gdb server. I think this has something to do with sigint, but I am not sure.

[Clem Taylor]

Try:

mon reset
load
mon reset
continue

The macro I use:

define rc
   # reset and halt CPU
   mon reset
   printf "Run...\n"
   continue
end 

define lc
   load
   rc   
end

For me 'lc' prints:

Loading section .text, size 0x151f8 lma 0x18000
Loading section .ARM.exidx, size 0x8 lma 0x2d1f8
Loading section .data, size 0xd8 lma 0x2d200
Loading section .fill, size 0xbd24 lma 0x2d2d8
Loading section .appCRC, size 0x4 lma 0x38ffc
Start address 0x6d0, load size 135168
Transfer rate: 13200 KB/sec, 3653 bytes/write.
Resetting target
Run...

I used to use 'load' then 'run', but that requires 'gdb extended-remote' mode and some point in the recent past Segger broke breakpoint support in 'extended-remote' mode.

I really don't trust the Segger stuff, I recently discovered if you load code onto a chip with the memory protection bits set, JLinkGDBServer will happily report:

Downloading 4096 bytes @ address 0x00018000 - Verified OK