Soft device assert

[vishal more]

We are using s110_nrf51_8.0.0_softdevice.hex soft device and nRF51 SDK v10.0. We have below questions in case of soft device assert scenario.

1. In what scenario's soft device will asserts?

2. How to recover from soft device device assert?

3. Can you explain what soft device does after assert_nrf_callback returns? Does soft device trigger system reset?

4. If we provide our version assert_nrf_callback where in if we don't reset the system then what will be behavior from soft device?

5. If we don't provide our version of assert_nrf_callback then any default __WEAK version of assert_nrf_callback get linked with application. If yes what is it's behavior?Will it reset the system?

Thanks in advance.

[Ulrich Myhre]

Hi Vishal,

When the SoftDevice asserts, it is because it absolutely cannot continue to operate. It could mean that some hardware peripheral did not respond in time, that the timers are inaccurate, or that some internal state is invalid. To make sure that the SD does not progress into undefined behavior, where it can break the Bluetooth specification or drain the battery, it will instead halt.

There is a chapter in the SoftDevice Specification (SDS) about asserts and error handling, but I can expand a bit on it:

1. The SoftDevice will assert if one of its critical assumptions about the future does not hold. This typically happens if you outstay your timeslot (requested by the Timeslot API), use a debugger to halt the CPU while in a BLE connection, or if a wrongly specced/configured timer is being used on the board. There are also some erratas on older chips, which make certain combinations of SoftDevices and chip revisions incompatible. Please refer to the Compatibility Matrix in the InfoCenter to make sure you are using a supported combination. In later versions of the S13x (and newer) SoftDevices, asserts will occur on memory accesses to restricted areas as well. Those use the "Nrf_fault" callback that can distinguish the assertion type.

2. The safest way to recover is to log the assert information, then reset. If the asserts occurs multiple times, you should open a support case.

3. This varies a bit between the SoftDevices unfortunately, but the assert callback should end with a reset and thus not return. In our newer SoftDevices, we trigger a HardFault to halt the chip if the callback fails to do so.

4. It depends on the SoftDevice if it will continue or not (even though it really should stop). The SoftDevice will disable all interrupts, and whatever happens after the assertion is undefined behavior.

5. It should HardFault. If your HardFault handler does not reset, the device will be halted until power cycled physically.

[Eric Smith]

"There is a chapter in the SoftDevice Specification (SDS) about asserts and error handling"

Which chapter is that? I can't find such a thing in the S132 5.1 specfication. I'm trying to debug a SoftDevice assert that happens if I leave the code running overnight. I'm reasonably certain that my code is to blame, but the assertion doesn't seem to provide me with any useful information as to what happened.

It really seems to me that the SoftDevice should be written to store information about the reason for the assertion somewhere that I can examine with a debugger. Just reporting "something is wrong, we're not going to tell you what" is extremely unhelpful. There must be a fair number of assertions in the SoftDevice code; even just knowing which one was hit would probably be helpful, in so far as I could tell you "assert on foo.c line 439", and you could identify what it was doing.

[Ulrich Myhre]

That's exactly what the SoftDevice does, though. When it asserts, it will call the SoftDevice fault handler, provided by the app during initialization. This function will be called with fault identifier, the program counter when the fault triggered, and some information related to the type of fault. This is described in S132 5.1 SDS in chapter 4.2 "Error handling", and partly in the documentation for sd_softdevice_enable and nrf_fault_handler_t. Before resetting, you can store this information for later, though you are unable to use sd-functions and must access peripherals directly.

The PC will be specific to a certain assert, and support is able to look up exactly what failed. Earlier we would embed the string of the failing source file, but that wasn't very helpful for code inside the stack. If the PC is pointing to you code, you can use addr2line to look up the exact file/line.