This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Graceful handling of softdevice asserts

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?

Parents
  • 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. 

Reply
  • 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. 

Children
No Data
Related