Back trace from hard fault handler with s110 flashed?

RE: Back trace from hard fault handler with s110 flashed?

Ole Morten — Mon, 10 Feb 2014 20:30:54 GMT

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!

RE: Back trace from hard fault handler with s110 flashed?

Andre Pang — Mon, 10 Feb 2014 18:18:23 GMT

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.

RE: Back trace from hard fault handler with s110 flashed?

Christopher Mason — Thu, 19 Sep 2013 12:52:52 GMT

Y'all are completely awesome. :) Thanks so much!

RE: Back trace from hard fault handler with s110 flashed?

Ole Morten — Thu, 19 Sep 2013 09:10:37 GMT

I'm sorry, it turned out that I was confused by Windows choosing a different GCC/GDB version than I expected. When I make sure to use 4.7q2, I see the same behavior you do.

A softdevice developer had a look on this, and it seems that this is caused by the softdevice's HardFault handler doing a BLX instead of a BX when jumping to the application's handler. Apparently, this causes GDB and other debuggers to get lost.

A fix for this should hopefully get into the final version 6.0.0 of the S110. Thanks for the help with reproducing this problem!

RE: Back trace from hard fault handler with s110 flashed?

Christopher Mason — Wed, 18 Sep 2013 03:22:44 GMT

Ole, I really appreciate you investigating, but I'm afraid I'm not seeing the same thing you are.

I just reconfirmed that I am indeed able to see backtraces in gdb from HardFault handlers when the soft device is not flashed on the NRF51822.

If I run this program:


#include <stdint.h>

void cause_hardfault(void)
{
    uint32_t * cause_hardfault = (uint32_t *) 0x1;

    uint32_t value = *cause_hardfault;
    (void) value;
}

int do_something(int unused) {
    cause_hardfault();
    return 1;
}

int main() {
    do_something(0);
    return 0;
}

And I compile, using gcc-arm-none-eabi-4_7-2013q2 like such:


arm-none-eabi-gcc -Wall -g3 -O0 -mcpu=cortex-m0 -mthumb -c main_crash.c
arm-none-eabi-gcc -Wall -g3 -O0 -mcpu=cortex-m0 -mthumb -c nRF51822.c
arm-none-eabi-gcc -Wall -g3 -O0 -mcpu=cortex-m0 -mthumb -c error.c
arm-none-eabi-gcc -O0  -g3 -mcpu=cortex-m0 -mthumb -TnRF51822-bare.ld -o main_crash.elf main_crash.o  nRF51822.o error.o -lg_s -lc_s -lrdimon

I then flash this on the chip with no soft device present.

I get this stack trace:


Breakpoint 1, main () at main_crash.c:17
17	    do_something(0);
(gdb) c

Program received signal SIGTRAP, Trace/breakpoint trap.
HardFault_HandlerC (hardfault_args=0x20003fa8) at error.c:58
58	    __asm("BKPT #0"  ) ; // Break into the debugger
(gdb) bt
#0  HardFault_HandlerC (hardfault_args=0x20003fa8) at error.c:58
#1  <signal handler called>
#2  0x000004e0 in cause_hardfault () at main_crash.c:7
#3  0x000004f8 in do_something (unused=0) at main_crash.c:12
#4  0x0000050e in main () at main_crash.c:17

I've also tried with -O2 and -Os. All of these work when I do not have the s110 stack flashed on the chip.

However, if I use the soft device ld file:


arm-none-eabi-gcc -O0  -g3 -mcpu=cortex-m0 -mthumb -TnRF51822-softdevice.ld -o main_crash.elf main_crash.o  nRF51822.o error.o -lg_s -lc_s -lrdimon

And flash it onto a chip where the soft device has also been loaded, I get this stack trace:

Breakpoint 1, main () at main_crash.c:17 17 do_something(0); (gdb) c


Program received signal SIGTRAP, Trace/breakpoint trap.
HardFault_HandlerC (hardfault_args=0x20003fa8) at error.c:58
58	    __asm("BKPT #0"  ) ; // Break into the debugger
(gdb) bt
#0  HardFault_HandlerC (hardfault_args=0x20003fa8) at error.c:58
#1  0x00011290 in ?? ()
#2  0x00011290 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

It's not necessary for the s110 to be active, but if it is flashed on the chip, then I get ?? backtraces like the ones shown in the above.

I've attached a zip of a project with Makefile that demonstrates this. Use:


make NRF51_USE_SOFTDEVICE=0 all
make clean
make NRF51_USE_SOFTDEVICE=1 all

to test. I use the JLink to clear the flash between runs so none of the soft device is left in flash.

I have to conclude that something about the presence of the s110 soft device causes gdb to not be able to report stack traces from hard faults.

Again, would it be possible for you to share the contents of the s110 HardFault handler function?

Thank you so much for your kind attention!

-c

RE: Back trace from hard fault handler with s110 flashed?

Ole Morten — Mon, 16 Sep 2013 11:13:29 GMT

Unfortunately, as far as I can see, there is something about a HardFault occuring that causes the GDB backtracing to be confused, no matter if the softdevice is currently on the chip or not.

When testing this, I've been using the following code to cause a hardfault in a simple program:


void cause_hardfault(void)
{
	uint32_t * cause_hardfault = (uint32_t *) 0x1;
	
	uint32_t value = *cause_hardfault;
	(void) value;
}

When running this, even with no softdevice on the chip, I'm not able to get any reasonable backtrace from any hardfault handlers. When inspecting memory manually, it does however seem that the stack isn't corrupted, but no matter what I try to set the current frame to, GDB won't give me any useful backtrace.

I have to admit that I'm on thin ice regarding my own knowledge here, so there could very well be some (potentially easy) trick that can be done to "explain" GDB how to read the stack. It would have been very interesting if either someone here, or someone on Stack Overflow could come up with something!

RE: Back trace from hard fault handler with s110 flashed?

Christopher Mason — Fri, 13 Sep 2013 14:37:32 GMT

I've attached the code, which comes directly from the link in my original post. Would it be possible to post the code from s110's hard fault handler? Does it have attribute((naked))? Does it just directly forward to the handler in my interrupt vector? I'm confused, based on reading docs [1], why both the Nordic and my fault handlers are not simply pushed onto the existing stack...

[1] http://infocenter.arm.com/help/topic/com.arm.doc.dui0497a/Babefdjc.html#BABDBGGA

RE: Back trace from hard fault handler with s110 flashed?

Ole Morten — Fri, 13 Sep 2013 09:52:39 GMT

I'm sorry for the delay, but I've been digging around a little today, experimenting with different handlers and inspecting the stack manually, and as far as I can see, this isn't really possible. However, to be a little more certain, it would have been useful to have a look at your HardFault handlers. Could you upload a code file with them here?

RE: Back trace from hard fault handler with s110 flashed?

Christopher Mason — Tue, 10 Sep 2013 19:43:54 GMT

Does anyone have an ideas here? Can I modify the fault handler somehow to give me access to the frame pointer? See also the same question at Stack Overflow: http://stackoverflow.com/questions/18640673/gdb-backtrace-from-hard-fault-handler-on-arm-cortex-m0-nrf51822