Significant osDelay Extension (10x Longer Than Set) in STM32WBA55 Running FreeRTOS+BLE

[lbo.1]

When using the NUCLEO-WBA55CG development board and running the BLE_HeartRateFreeRTOS example, I found that the delay time of osDelay is extremely long, nearly 10 times longer than the set delay time. What is the cause of this and are there any solutions?

[coppercrimp]

Question: Do you use HAL_SuspendTick() function anywhere in your code? Perhaps before entering sleep or stop mode? I had a similar problem once and traced the problem back to the suspension of the Tick Timer. I was also using tickless idle mode in FreeRTOS. I switched from using osDelay() to HAL_Delay() and it fixed the problem

[ahsrabrifat · Accepted solution]

The primary cause of the apparent slowdown is a mismatch between the system clock and the FreeRTOS tick configuration. If SystemCoreClock isn’t updated correctly before FreeRTOS initializes, or if the tick source gets reconfigured without notifying the RTOS, then each RTOS tick may no longer represent the intended 1 ms. In certain board examples like the BLE demo on WBA55CG, this mismatch can stretch delays to around ten times longer than expected. Essentially, vTaskDelay() (which osDelay() calls internally) is counting ticks, not milliseconds.

To fix this, ensure that after the clock setup in your system initialization, you call SystemCoreClockUpdate() so that FreeRTOS knows the correct clock frequency. Additionally, verify configSYSTICK_CLOCK_HZ and configTICK_RATE_HZ in your FreeRTOSConfig.h still align with your hardware configuration. If the SysTick is used as the RTOS tick source—and isn’t updated to reflect a newer clock rate—the RTOS will miscalculate the duration of each tick. ST forums confirm that if the timebase source or system clock changes without proper RTOS updating, then delays can end up being extended by unintended multipliers.

Alternatively, if the HAL tick is coming from a different timer (e.g., TIM6 or TIM7) while FreeRTOS still uses SysTick (or vice versa), this can create divergence between HAL_Delay() (which relies on the HAL tick) and osDelay() (which relies on the RTOS tick). A common workaround is to switch the HAL timebase source to a timer that doesn’t conflict with FreeRTOS's tick, or align both mechanisms to use the same base frequency. This way, both delay functions work consistently and avoid unexpected timing artefacts.

For a look into a different embedded environment combining Rust and FreeRTOS, you might find this article interesting: Running Rust and FreeRTOS on the PADI IoT Stamp

[coppercrimp]

Ahsrabrifat, thank you for that very detailed and helpful explanation