RTOS Thread Issue After Switching to STM32U5A5QJI6Q

[Sakthi_IND]

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:

1. If so, what is the recommended way to ensure proper SysTick handling in STM32U5A5QJI6Q with RTOS?
2. Are there any CubeMX configuration changes required for this MCU variant?
3. what is the use of SysTick?

We would appreciate your guidance in resolving this issue.

Regards,

Sathiya

[Saket_Om]

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.

[Sakthi_IND]

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

[Sakthi_IND]

Hi,

We previously used the STM32U5A5VJT6Q (100-LQFP package) in our design. For size optimization, we have migrated to the STM32U5A5QJI6Q (BGA package). Both MCUs are functionally similar, and we have updated the pin configurations accordingly.

Our application involves reading data via SPI from the Infineon BGT60TR13C radar chip, which uses the following pins: MOSI, MISO, CS, CLK, RST, and IRQ. The previous version worked without any issues.

However, in the new version using the BGA package, we are encountering a problem: the RTOS thread runs at regular intervals but does not stop as expected, causing the record number to reach its maximum count. We have attempted several debugging steps, but the issue remains unresolved.

Could this be related to a hardware-level difference between the 100-LQFP and BGA packages, or is there a configuration change required for the new MCU?

Any suggestions would be appreciated.

Regards,
Sathiya

[Saket_Om]

Hello @Sakthi_IND 

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

Did you try with the same systick config ?

[Sakthi_IND · Accepted solution]

Hi Saket_Om,

Thank you for your response. The issue seems to be with the IRQ pin of the BGT60TR13C radar chip. We tested it with a new board, and it worked fine.

Thanks again for your continued support and efforts.

Best regards,
Sathiya