Graceful handling of softdevice asserts

[himanshu pande]

We have an application where certain executions hold more priority over BLE link. We are implementing a critical section(disable/enable interrupts). However, in some corner cases, the softdevice asserts. We do not mind losing the BLE link.

Is there a way to handle this assert in a graceful way without resetting the microcontroller? Also, since I read that softdevice assert is in hard fault context, is this even possible to handle without resetting?

[Turbo J]

himanshu pande said:

We are implementing a critical section(disable/enable interrupts).

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.

[himanshu pande]

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.

[Vidar Berg]

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.