RE: Hardfault after debug pause and start(NRF52, S132-SD-v2)

M. Hoffmann — Tue, 01 Dec 2015 11:29:58 GMT

Hi Hakon,

Here is some extra information:

We checked and we define the DEBUG symbol in the project and the PC = 0x00030706 must have been the HardFault_Handler.

We found that the warning about the T-bit of the XPSR register has something to do with the implementation of the hardfault handler.

HardFault_Handler:

b	.

instead of the default handler. The warning is not visible when the default handler is used.

When we used gdb from commandline and used backtrace, this was printed on the console:

Program received signal SIGTRAP, Trace/breakpoint trap.

0x000250ec in ?? ()

(gdb) backtrace

0 0x000250ec in ?? ()

1 0x000250d6 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

But the processor did not end up in hardfault! All backtrace addresses are valid addresses that in application code.

We should check our LPCxpresso settings.

RE: Hardfault after debug pause and start(NRF52, S132-SD-v2)

Håkon Alseth — Tue, 01 Dec 2015 09:56:56 GMT

Hi,

The address you're referring to is in the application space, which means that this is where the HardFault occurred. If you look at your .map file generated, I would assume this is where your application has placed the implementation of the HardFault_Handler() function in flash. In GDB you should be able to do a 'backtrace' cmd to see where the call stack (would recommend -O0 optimization to get this a bit more "readable" format).

This is not an uncommon feature when stop/starting while debugging. This will essentially halt the MCU core until you resume, but keep peripherals, such as timers/RTC/radio/etc, running. The S132 stack itself will therefore service interrupts in a state which it should not be in, and throw an exception to the application (softdevice_assertion_handler->assert_nrf_handler->app_error_handler).

If you have not set the define "DEBUG" in your project, the default behavior on an assert is a NVIC_SystemReset(), which may give warnings equal to yours. Could you ensure that -DDEBUG is added to your makefile and see if you get a blocking assert?

Cheers, Håkon