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

[M. Hoffmann]

We have used the first version of the S132 softdevice with the Engineering A version of the nrf52 chip. Now with the newer Engineering B version, we have moved to the second version of the S132 softdevice. Since this version, we started to have some issues with debugging.

When we were using the older softdevice we had little to no problems when we would pause and start the debugger again(to check some values for instance). Although Bluetooth was no longer working(which we expected), other parts such as UART and TWI(for I2C) would still work. Now, when we pause and start the debugger or when we add a breakpoint, a hardfault occurs.

In the GDB log we see something that seems strange to us and could be the problem:

---

Starting target CPU...

WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1.

...Target halted (PC = 0x00030706)

---

The "0x00030706" is the hardfault handler address of course.

Somehow, the T-bit is set to 0 and j-link sets it to 1. (the older softdevice does not have this issue) We have researched this, and it seems it should not be possible for this bit to become 0 in our situation.(we only use thumb instructions as far as we know)

We have tested this both in Keil(modified an example from the latest SDK to work with S132-SD-v2) and in GCC (our own code using LPCXpresso, an eclipse derivative). We have the latest j-link software (V5.02k) installed.

Because there isn't a supported SDK yet for S132-SD-v2, we can't check this issue with a verified example.

We would like to know if somebody could help us with this issue as it slows down our development right now.

[Håkon Alseth]

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

[M. Hoffmann]

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.