Graceful handling of softdevice asserts

RE: Graceful handling of softdevice asserts

Vidar Berg — Mon, 28 Jan 2019 13:05:18 GMT

Hi,

Interrupts should not be disabled globally as it will delay servicing of timing critical protocol events inside the softdevice, hence lead to an assert. If you need a critical section it's recommended to use the CRITICAL_REGION_ENTER()/CRITICAL_REGION_EXIT() macros. These will only mask the application level interrupts, or that's what it should do. The softdevice reserved MWU (used to "sandbox" softdevice memory) peripheral is wrongfully masked even if you use the macro. The fix for that is to redefine __NRF_NVIC_SD_IRQS_1 to __NRF_NVIC_SD_IRQS_1 ((uint32_t)(1U << (MWU_IRQn - 32))) in the nrf_nvic.h header.

Can you try to implement the changes mentioned above and see if you still get the asserts? I'm not sure if it's possible to safely recover from an assert without doing a reset.

RE: Graceful handling of softdevice asserts

himanshu pande — Mon, 28 Jan 2019 12:52:29 GMT

Hi Turbo,

That does not answer my question. Could you elaborate more on "cannot be safely handled". Like I said, we do not mind losing the BLE link. The critical sections are working fine for us as well.

Is there a way I can completely reinitialise the software from the point where assert is encountered.

Best Regards,

Himanshu.

RE: Graceful handling of softdevice asserts

Turbo J — Mon, 28 Jan 2019 00:39:08 GMT

[quote userid="15741" url="~/f/nordic-q-a/43058/graceful-handling-of-softdevice-asserts"]We are implementing a critical section(disable/enable interrupts).[/quote]

Don't do that - softdevice interrups can be very timing critical. Either use timeslot API or disable the softdevice altogether.

And no, those asserts cannot be safely handled without a device reset.