Running SoftDevice with FreeRTOS: nrf_delay_ms in another thread crashes program

[Octopopit]

Hello,

We are writing an application that relies heavily on two FreeRTOS tasks of equal priority. One handles BLE via the SoftDevice and the other handles communication with a cellular module via the FreeRTOS Cellular Interface Library. Preemption and time-slicing are both enabled.

Our problem is this: The two thread works perfectly fine when the other is commented out. When running at the same time though, the application freezes.

I had trouble getting GDB to cooperate while the SD was running, so I stepped through the program with printf. The part that seems to be giving us the issues is whenever we call nrf_delay_ms() in the cellular thread. Since the BLE thread is of equal priority and time-slicing is turned on, I would expect this delay to NOT interfere with that thread. 

We tried changing nrf_delay_ms() to vTaskDelay(), but that is a problem because there is a cellular sub-thread that should not run until the main thread has completed this section of code.

Any help would be appreciated, please let me know if there are additional details that would be helpful. Thank you!

Details:

-nRF52840

-S140 7.2.0

-nRF5 SDK 17.1

-VS Code on Windows

[Susheel Nuguru]

Hi,

You cannot use nrf_delay_ms in a timeslicing equal priority tasks as this is busy wait and the time it takes to expire relies on how much time the task is running (getting the CPU) in which this delay is called.

We can't expect busy waits to have predictable time expiry on a multitask environment with preemption and timeslicing enabled. The predictability comes only if you use hardware RTC or internal RTOS soft timers like vTaskDelay().

but that is a problem because there is a cellular sub-thread that should not run until the main thread has completed this section of code.

You should solve that using inter-task communications to make one thread wait for the other one to finish a task. 

[Octopopit]

Hi, thank you for the response! That makes sense.

I switched from using nrf_delay_ms to vTaskDelay with a binary semaphore to control the subtask, which fixed that issue but we were still having the software crash during the delay.

We did not realize that the SoftDevice blocks use of Timer0, which we were trying to use with libuarte. I switched it to timer2, and everything started falling into place. 

Thanks again for your help.

[Susheel Nuguru]

Great that it all worked out for you. Good that you came back here to post the fix with switch with timer2 for other community members to know of the common traps to be aware of in this setup.