Application fault in SoftDevice

Question

Hi, 
 
 My device is using nRF52840 with s140 of SDK v16. BLE feature is used with SD . 
 Sometimes application hard faults in SD are observed in devices deployed. It is quite random. 
 Its PC is 0x1505C and fault id is 1. 
 Would you let me know when this assertion is raised on SD?

Marjeris Romero · Accepted Answer

Hi BS, 
 Håkon is on vacation so I am taking over this case for now. 
 Both asserts have to do with radio event manager in Timeslot API. From your code it doesn't seem like you ending the timeslot, since only NRF_RADIO_SIGNAL_CALLBACK_ACTION_NONE is returned, but NRF_RADIO_SIGNAL_CALLBACK_ACTION_END is never returned. 
 Perhaps the asserts can be resolved if stopping the timeslot a bit earlier? 
 Best regards, 
 Marjeris

Marjeris Romero · Answer

Hi Jake, 
 Hakon said: What most likely happens when you get assert 0x25B94 is that you spend too much time in the p_radio_signal_callback handler that is passed to sd_radio_session_open(). 
 This was Håkon's suggestion for what could be happening when you get assert 0x25B94. I agree with Håkon that it's very likely that you in some way are overstaying your allocated timeslot. You say that you return from the p_radio_signal_callback handler as soon as possible but I cannot see that from the code snippet you posted earlier. Can you post the code where you return NRF_RADIO_SIGNAL_CALLBACK_ACTION_END? 
 You need to end the current timeslot by returning either: 
 NRF_RADIO_SIGNAL_CALLBACK_ACTION_END, /**< End the current radio timeslot. */
NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END /**< Request a new radio timeslot and end the current timeslot. */ 
 For the differences between the two asserts I asked one of our Softdevice developers and this was the explanation he gave: 
 0x01505c is an assert in the REM low architectural level, it can happen if a role (bluetooth advertiser, bluetooth connection ++, or timeslot api) spends more time than they requested. This assert can happen if the application disables interrupt globaly at unfortunate times, or has missconfigured one of its interrupts to have highest priority. 0x025b94 is in the timeslot api implementation, so higher up in the architecture than 0x01505c, it tries to "catch" when the application has spent to much time in its timeslot. Keep in mind you might get 0x01505c instead of 0x025b94 if you spend to much time in a timeslot. 
 So as you can see both asserts are kind of intertwine, and indicate that the application has overstayed its allocated timeslot. Have you tried to debug your timeslot implementation in some way? 
 
 Best regards, 
 Marjeris

Application fault in SoftDevice

Top Replies