STM32 FreeRTOS clock issue

[SavitaDhiman]

Device and Software Configuration Details:

• MCU Full Part Number: STM32L010RB
• Development Environment:
1. Utilizing Visual Studio with the STM32 VS Code Extension.
2. Configured the development setup using STM32CubeCLT, which includes STM32CubeMX, toolchain, debugger, and flashing tools.
3. Employed STM32CubeMX to set up the Nucleo-L010RB board for FreeRTOS under CMSIS_V2 specification. Notable adjustments include:
• Changed the clock source to TIM22 to align with best practices in RTOS environments, avoiding the use of sys_clk.
• Generated the base code with default configurations.

Challenges Encountered:

We are experiencing challenges with the OS clock/timers — specifically, calls to osDelay() result in the application hanging. Similar issues are observed when attempting to create and use timers.

Inquiry:

Could there be additional configurations required for the system clock or OS clock source to ensure proper functionality within a FreeRTOS context? Any guidance or suggestions in this regard would be immensely valuable.

I would greatly appreciate any help on the issue.

Thanks and Regards

Savita Dhiman

[nouirakh]

Hello @SavitaDhiman 

Although osDelay() is relatively straightforward to utilise, it is possible for certain errors to arise, which may result in the delivery of incorrect delays or even system crashes.

The following are some typical reasons why osDelay() may not function as anticipated:

• Invalid system timer configuration – If the system timer is not set up properly or disabled, osDelay() will be unpredictable.
• If you disable interrupts, the SysTick interrupt can't decrement the delay counter, so delays are much longer.
• If the processor is overwhelmed with interrupt requests, the SysTick interrupt may not fire consistently, affecting osDelay().
• Incorrect configuration of RTOS can result in issues such as priority inversion or resource starvation, which can subsequently affect thread scheduling and timing.
• You can't call osDelay() from an ISR or with interrupts disabled. This can lock up the system.
• If the delay period is too long, the SysTick counter can roll over, which can cause delays to be incorrect.
• The use of multiple timing sources may result in a conflict between the timers employed by some ISRs and SysTick, potentially affecting the accuracy of osDelay().

Debugging delays will help you identify the issue:

• Check the SysTick configuration. Make sure the settings match your system and RTOS needs.
• Verify interrupts enabled – Set a breakpoint at the start of osDelay() to check if interrupts are already disabled before it is called.
• Inspect interrupt handler – Step through the SysTick handler code to ensure it is behaving correctly and decrementing the counter.
• Measure execution times – Use profiling or an oscilloscope to find ISRs or code segments that are taking too long to execute and fix accordingly.
• It is possible to alter the thread priorities by increasing the priority of threads and ISRs using the osDelay() function. This will prevent them from being blocked for an excessive period of time.
• Confirm units Make sure the delay is specified in milliseconds. A common mistake is using microseconds instead.
• It is advisable to ascertain the speed of the timer in order to determine the length of any delays. It is likely that a 1 MHz SysTick timer will prove inadequate in this context. It would be prudent to select a timer with a faster speed.
• Aware of timer resolution – There is only 1 tick per millisecond, so delays below 10 ms may measure as 0 ms.
• Inspect compiler optimizations – Aggressive optimizations may eliminate or alter the delay loop code.
• It is recommended that the RTOS scheduler be verified. It may be the case that short delays are simply skipped if the RTOS reschedules a thread immediately.