Soft Device Freeze NUS, Scan, FreeRtos

RE: Soft Device Freeze NUS, Scan, FreeRtos

WestCoastDaz — Sat, 20 Feb 2021 23:38:45 GMT

I am currently using FreeRTOS in that fashion and I haven’t had an issue.

RE: Soft Device Freeze NUS, Scan, FreeRtos

LukeC — Fri, 19 Feb 2021 05:50:23 GMT

So, I found another thread that proposed removing the SDH task and using the interrupt dispatch model.

Is there any extra risk from this approach? It seems to have fixed the issue, I can even push scanning to 20ms window / 10ms interval.

// <i> NRF_SDH_DISPATCH_MODEL_INTERRUPT: SoftDevice events are passed to the application from the interrupt context.
// <i> NRF_SDH_DISPATCH_MODEL_APPSH: SoftDevice events are scheduled using @ref app_scheduler.
// <i> NRF_SDH_DISPATCH_MODEL_POLLING: SoftDevice events are to be fetched manually.
// <0=> NRF_SDH_DISPATCH_MODEL_INTERRUPT 
// <1=> NRF_SDH_DISPATCH_MODEL_APPSH 
// <2=> NRF_SDH_DISPATCH_MODEL_POLLING 

#ifndef NRF_SDH_DISPATCH_MODEL
#define NRF_SDH_DISPATCH_MODEL 0
#endif

RE: Soft Device Freeze NUS, Scan, FreeRtos

LukeC — Fri, 19 Feb 2021 05:38:36 GMT

I have been concerned about that as well, but I think I have the priorities set right.

All of my tasks are either priority 0 or 1 while the SDH task is priority 2.

If I pause when the stack freezes, I see the IDLE task as the one executing, which indicates the BLE task is not blocking. It sure seems like it is the soft device locking up which runs at a higher priority than any of the FreeRtos tasks...

RE: Soft Device Freeze NUS, Scan, FreeRtos

WestCoastDaz — Fri, 19 Feb 2021 02:28:28 GMT

LukeC

What are the task priorities? The BLE task should be high if not the highest. Note that in FreeRTOS a high number means a higher priority.