2025-07-15 6:03 AM
Hi Team,
we are currently developing a product using the STM32U5 series. In our previous version, we used the STM32U5A5VJT6Q, and for size optimization, we have migrated to the STM32U5A5QJI6Q. Both MCUs are functionally similar, and we have updated the pin configurations accordingly.
We are successfully reading data from a radar sensor using the new MCU. However, we are facing an issue where the RTOS thread does not stop properly, and the record number reaches its maximum count. Upon comparing the old and new firmware, we noticed that the Configure the Systick function is present in the old version but missing in the new one.
We suspect that the absence of this function might be causing the RTOS timing issues. We also found a similar unresolved query on the ST Community forum from 2018 regarding CubeMX and SysTick behavior(CubeMX and SysTick - STMicroelectronics Community).
Could you please confirm:
We would appreciate your guidance in resolving this issue.
Regards,
Sathiya
2025-07-15 8:00 AM
Hello @Sakthi_IND
It is important to understand that when using an RTOS like FreeRTOS, the SysTick timer is typically reserved exclusively for the RTOS kernel’s system tick. This timer generates the periodic interrupt that drives the RTOS scheduler, enabling task switching and time management.
Using SysTick for other timing purposes or reconfiguring it outside the RTOS context can cause timing conflicts and unpredictable behavior.
It is recommanded to keep SysTick dedicated to FreeRTOS for its system tick interrupt.
For other timing or delay requirements in your application, use one of the STM32U5’s general-purpose hardware timers (TIMx) as a separate timebase.
2025-07-15 9:52 AM
Hi Saket_Om Thanks for your response!
Yes, we are using a separate timer—Timer 1—for our application timing needs.However, we’re facing an issue where the RTOS thread runs at equal intervals but does not stop as expected, causing the record number to reach its maximum count. We suspect this might be due to a configuration issue.
Could you please advise if any specific configuration is required to ensure the thread stops or suspends correctly? Also, is there anything we should double-check in the task delay, priority, or timer interrupt handling that might be affecting the thread's behavior?
Regards,
Sathiya