I'm using Nordic NRF51822 and the Segger JLink with the s110 Bluetooth stack active (correction: flashed on the chip, see below). When my code hard faults (say due to a dereferencing an invalid pointer), I see only the following stack trace:
(gdb) bt
#0 HardFault_HandlerC (hardfault_args=<optimized out> ) at main_display.cpp:440
#1 0x00011290 in ?? ()
I have a hard fault handler installed (see attached file) and it can give me the lr and pc:
(gdb) p/x stacked_pc
$1 = 0x18ea6
(gdb) p/x stacked_lr
$2 = 0x18b35
And I know I can use addr-to-line to translate these to source code lines:
> arm-none-eabi-addr2line -e main_display.elf 0x18ea6
/Users/cmason/code/nrf/src/../libs/epaper/EPD_Display.cpp:33
> arm-none-eabi-addr2line -e main_display.elf 0x18b35
/Users/cmason/code/nrf/src/../libs/epaper/EPD.cpp:414
Can I get the rest of the backtrace somehow? If I stop at a normal breakpoint I can get a backtrace, so I know GDB can do the (somewhat complex) algorithm to unwind the stack on ARM. I understand that, in the general case, the stack may be screwed up by my code to the point where it's unreadable, but I don't think that's what's happening in this case.
I think this may be complicated by the s110 memory protection scheme. I'd guess that the Nordic Hard Fault handler is at 0x00011290 and that it is executing on an alternate stack from my code. Nordic's Hard Fault handler is calling mine.
Can I somehow get GDB to display the stack trace of my (user mode) stack instead of this special protected mode stack?
Thanks!
-c
