SDK 12.2, S132 v3.1.0, softdevice_fault_handler at PC=0x10A62

[Frederic Courchesne]

I searched in this forum about softdevice_fault_handler errors, but could not find the cause of my problem. I need to obtain more information for a softdevice_fault_handler at PC=0x10A62. This assert error coming from the SoftDevice occurs at random times. Sometimes after 25 seconds only, but mostly after more than 2000 seconds of running time.

Here is my setup:

1. Keil v5.17
2. nRF5 SDK 12.2.0 f012efa
3. SoftDevice v3.1.0
4. MCU NRF52832QFAA

Initially developped on the PCA10040, I am now running my app on our own target. The app is a BLE scanner always listening for specific advertisement messages. JSON packets are outputted on UART when a valid Beacon is detected. UART TX has been done in two different ways to try to solve this. 1) printf() was called directly in the BLE event interrupt handler and 2) printf() is now called in the main loop, by using a circular buffer to store the advertisement packets. In both situation, I get the softdevice_fault_handler at random times. Since it seems related to timing, here is more information:

• SCAN parameters are as follow

static const ble_gap_scan_params_t m_scan_param =
{
 .active = 0,
 .interval = SCAN_INTERVAL, //0x3E80
 .window = SCAN_WINDOW, //0x3E80
 .timeout = SCAN_TIMEOUT, //0 
 .use_whitelist = 0,
 .adv_dir_report = 0,
};

• RTC0 is enabled for SoftDevice.
• RTC1 for the app_timer library. Only one single shot timer is used. APP_TIMER_KEEPS_RTC_ACTIVE = 0
• RTC2 is enabled only to increment a counter each 100ms. Init with NRF_DRV_RTC_DEFAULT_CONFIG.
• SeggerRTT logging is fully enabled for each and every modules having a xxx_CONFIG_LOG_ENABLED in sdk_config.h. Backend output buffer = 512

.

Thank you for your help on this.

Fred

[Susheel Nuguru]

This assert is inside the softdevice handler scheduler at the time when the radio timeslot ends. The scheduler sees that the radio timeslot is ending later than the time allocated for it. 

If your application is not using radio timeslot API, then this means that softdevice did not manage to end the timeslot allocated to itself in time. This will happen, if your application has some activity in interrupt service routine with a priority that is not allowed by the softdevice.

I would advise you to check all the enabled interrupts in your application and see if you have set the priority of the interrupt to the one allowed by the softdevice. If you forget to set the interrupt priority of any interrupt, then it by default takes the highest priority (value 0) which is not allowed for applications using softdevice.