Back trace from hard fault handler with s110 flashed?

[Christopher Mason]

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

hard_fault_handler.c

[Andre Pang]

Hi Chris,

Just letting you know that if you're still using SoftDevice 5.x, you can fake a proper backtrace in gdb by replacing the link register yourself. I had a look at your HardFault_Handler code that you posted, and since you call a C-based HardFault_HandlerC function, you can correct the backtrace before hitting your C function. Add something like

// Load MSP into R0 (replace with PSP if appropriate) mrs r0, msp // Replace LR (which SoftDevice stomped on) with the stacked LR ldr r2, [r0, #24] mov lr, r2

to your asm HardFault_Handler. That'll correct the LR before HardFault_HandlerC gets hit, so gdb can print out a nice happy backtrace. Works For Me.

And thanks a ton for your HardFault_Handler code! I'm completely new to firmware programming as of a few months ago, and am very happy that I have a handler that'll log all our application crashes. (Not that our app ever crashes, of course.) Much appreciated.

[Ole Morten]

Finding the correct link register value on the stack is actually a very neat trick that I didn't think about at the time. Thanks for posting!