Softdevice Random Hardfault at 0x00001398

RE: Softdevice Random Hardfault at 0x00001398

Kenneth — Thu, 28 Oct 2021 09:06:02 GMT

It's not something we have seen before, the theory is that there is a bug in the application (rather than the softdevice), and the bug corrupts the callstack and somehow return to wrong address on exception return. This theory might be strengthen if you also experience other hardfaults, are they allways CAFEBABE in PC and 0x1398 in LR.. or if there is sometimes other content.

You may check if you have any application interrupts at all above SVC priority.. those should be prio 2 or 3, since prio 0 and 1 is reserved by the SD, and prio 4 is what the SVC is using.

I think if you experience the problem again you should try to read out the hardfault status registers, this might help understand what actually caused the hardfault.

Kenneth

RE: Softdevice Random Hardfault at 0x00001398

SteamingGizmo — Wed, 27 Oct 2021 18:00:23 GMT

We are using the NRF52832 rev. AAEO with softdevice variant s132 running version 7.0.1.
We do not write or modify the MWU peripheral.

Unfortunately this was the only time we have been able to catch this hardfault with the debugger connected.
I didn't realize you could save the state with the ozone debugger, I will do this if I am able to catch it in action again.
As such, I do not have a full register dump or call stack to look over anymore.

When I did catch it, I was able to see 0xFFFFFFFE in the link register.
Ozone displayed one level up in the call stack, which had a the register values of
PC: 0xCAFEBABE
LR: 0x00001398

I know this isn't much information to work with, but any idea on direction would be immensely helpful.

RE: Softdevice Random Hardfault at 0x00001398

Kenneth — Wed, 27 Oct 2021 11:47:08 GMT

Hello,

Can you specify which nRF52-variant you are using and which softdevice variant you are using?

Do your application ever write to or modify the MWU peripheral?

Also, are you able to do a full register dump and/or callstack?

Thanks,
Kenneth