How to debug when `fault_handler` callback? about nrf-softdevice HOT 6 CLOSED

Unfortunately, debugging softdevice faults is not fun as it's mostly a black box. Also unfortunately, unwinding through the softdevice doesn't work as GDB lacks the debug info, that's just the way it is :(

id=1 indicates an assertion inside softdevice's code failed. In that case searching Nordic's forums for the PC value usually helps. For PC=0x16ACC I could find this thread which indicates it's an interrupt timing issue.

The softdevice is very picky about timing because the BLE radio requires very precise timing to sync with connected devices. You must not do anything that causes softdevice's interrupts to be delayed:

• Use interrupt functions from nrf_softdevice instead of cortex_m. These ensure only the non-softdevice interrupts are ever disabled.
• you can't use GDB breakpoints. They do work but as soon as you resume the softdevice notices the timing is off and asserts. That's just the way it is, haven't found a workaround :(
• Haven't personally tested it, but I think semihosting won't work either since it involves pausing the CPU too. Are you using it for logging? If so, consider switching to uart, rtt or defmt.

from nrf-softdevice.

i not use breakpoints. and olny use semihosting when panic.
Unbelievable, the bug has disappear, when i build with --release.

from nrf-softdevice.

i want to use probe-run, but it not work on my windows. both jlink and dap-link.
have you try to use probe-run on windows?

from nrf-softdevice.

You probably have something blocking the softdevice interrupts. Compiling with --release makes your code faster, so it's less likely to break softdevice's timing, but it's still not guaranteed.

• Check that you're NOT using cortex_m::interrupt::free or other cortex_m functions. Use functions from nrf_softdevice::interrupt instead.
• Check that you're not using interrupt priorities 0 and 1 (highest levels). If your interrupts have these priorities, they can delay softdevice's interrupts. Priority is 0 by default, so you have to change it manually.

Yes, probe-run works on Windows but you'll have to fiddle with USB drivers (using Zadig for example)

from nrf-softdevice.

How to solve this bug?
panicked at 'fault_handler 4097 285196 0'

only happen when build without --release.

from nrf-softdevice.

This is the same as https://github.com/akiles/embassy/issues/42 .

When you get a softdevice fault, check the NRF_FAULT_ID. In this case it's NRF_FAULT_ID_APP_MEMACC. Docs on it say this:

Application invalid memory access. The info parameter will contain 0x00000000,
in case of SoftDevice RAM access violation. In case of SoftDevice peripheral
register violation the info parameter will contain the sub-region number of
PREGION[0], on whose address range the disallowed write access caused the
memory access fault.

The PC value points to somewhere in your code where presumably the bad access happened. I'd check what's in there and go from there.

from nrf-softdevice.