Pinpointing hard faults caused during SoftDevice execution more effectively

RE: Pinpointing hard faults caused during SoftDevice execution more effectively

Susheel Nuguru — Thu, 07 Dec 2023 06:58:11 GMT

oldmud0,

A great number of times I have had been dealing with stack corrupted hardfaults and hence was thinking in that direction aswell. I haven't used the GDB that much myself but I believe that you have seen this message about "backtrace stopped" enough number of times with valid stack frames. So I trust you and believe that the stack frame is still sane.

[quote user="oldmud0"]Maybe in the future, I should try unwinding the stack pointed to by the PSP and seeing what's there, since that's application code and it'll give me the general area of where the fault occurred on the application side.[/quote]

OK, you seem to know your stuff. That might be helpful actually if you put a breakpoint in components\libraries\hardfault\nrf52\handler\hardfault_handler_gcc.c and get the application context from there instead of the softdevice context that caused this hardfault.

RE: Pinpointing hard faults caused during SoftDevice execution more effectively

oldmud0 — Wed, 06 Dec 2023 17:33:58 GMT

Hi Susheel,

Thanks for your answer. This reference bootloader already contains an app_error_fault_handler method (main.c:86). It was not triggered.

When the error message says "return address in the stack frame is not related to the instruction that caused the error," I believe it is referring to the fact that this data bus error is an asynchronous bus fault (IMPRECISERR) and therefore the instruction that the processor stopped at may not have been the instruction that caused the error.

"Backtrace stopped: previous frame identical to this frame (corrupt stack?)" is a generic note from GDB, and it doesn't mean that the stack was corrupted. The stack can change due to context switches, and I usually ignore this message unless the backtrace looks really messed up with garbage addresses. As the SoftDevice is a hard real time system that raises and handles interrupts, it makes sense to me that the stack only traces back to the SoftDevice.

Maybe in the future, I should try unwinding the stack pointed to by the PSP and seeing what's there, since that's application code and it'll give me the general area of where the fault occurred on the application side.

Apparently, the switch between PSP and MSP does trip people up and cause them to believe that the stack might have been messed up somehow.

RE: Pinpointing hard faults caused during SoftDevice execution more effectively

Susheel Nuguru — Wed, 06 Dec 2023 10:49:12 GMT

[quote user=""]However, it seems like the SoftDevice doesn't have a way of signaling clearly, "Hey, this hard fault happened during X operation." Or, when flash erase/writes are happening, the SoftDevice should handle hard faults momentarily to catch the error so it can be sent back as an event. Otherwise, the context of the error is lost.[/quote]

Softdevice do have a way to signal faults through the app_error_fault_handler if the softdevice has asserted or there is a hardfault in the softdevice. But I think in this case the whole debug method is based on the fact that you think the hardfault info that is pulled from the stack is uncorrupted.

Both the logs and you GDB tells you that the stack frame does not look sane

<error> hardfault: Cause: Data bus error (return address in the stack frame is not related to the instruction that caused the error).

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

These normally means that the stack frame does not look sane and most likely corrupted. In such cases hardfault debugging becomes even more manual and there is given way to debug. The stack frame could be corrupted by many reasons and it is not necessarily caused by softdevice.