Running SoftDevice with FreeRTOS: nrf_delay_ms in another thread crashes program

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

Parents
  • 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. 

Reply
  • 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. 

Children
Related