Scheduler get full by NRF_EVT_RADIO_BLOCKED events during connect.

Question

Using: 
 
 nRF52832 
 SDK 15.3.0 
 SD S132 6.1.1 
 nRF5 SDK for Mesh 3.2.0 
 NRF_SDH_DISPATCH_MODEL == NRF_SDH_DISPATCH_MODEL_APPSH 
 
 Hi, I'm often getting a crash when connecting. The back trace showed hints of it happening in the mesh code: timeslot.c handling event NRF_EVT_RADIO_BLOCKED. 
 But later I found out it actually happens because the app scheduler is full, while nrf_sdh.c tries to add a SD event on the scheduler: ret_code_t ret_code = app_sched_event_put(NULL, 0, appsh_events_poll); 
 When logging SOC events, I noticed many NRF_EVT_RADIO_BLOCKED events coming in when a connection is made. And when inspecting what happens, I saw that timeslot.c simply keeps on requesting a new timeslot until it succeeded. 
 Am I right to assume this timeslot request loop can lead to the scheduler getting filled up (especially when other processes also add to the scheduler)? And if so, is there a solution for this?

Mttrinh · Accepted Answer

Hi, 
 From speaking to one of our developer he thinks there are two potential solutions to this: 
 1. Reduce TIMESLOT_BASE_LENGTH_SHORT_US so it can fit between two connection events of the shortest type. This is the intent of the current functionality, but some condition on the device (configuration, clock drift setting?) is preventing the device from getting this short timeslot. Currently, it's 3800 us, try changing it to 3000, for instance. 
 2. Add some backoff mechanism in the BLOCKED event handler. In this handler, we're currently setting the timeslot request length to TIMESLOT_BASE_LENGTH_SHORT_US before retrying. If we end up here, and the request timeslot length is TIMESLOT_BASE_LENGTH_SHORT_US already, try starting a backoff timer that comes back to request a timeslot later. This could also be implemented as an nrf_mesh_evt_t, but that might still be too tight of a loop.

Scheduler get full by NRF_EVT_RADIO_BLOCKED events during connect.

Top Replies