RTEMS | stm32h7/bspstart: avoid overflow in HAL_GetTick calculation (!1144)

[Mohamed Ayman (@mohamedayman23)]

Mohamed Ayman created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1144

Project:Branches: mohamedayman23/rtems:fix-issue-stm32h7-bspstart to rtems/rtos/rtems:main
Author:   Mohamed Ayman



stm32h7/bspstart: avoid overflow in HAL_GetTick calculation

Potential Integer Overflow in HAL_GetTick():

Original code multiplies ticks since boot by milliseconds per tick using 32-bit arithmetic:

uint32_t HAL_GetTick(void) { return rtems_clock_get_ticks_since_boot() \* rtems_configuration_get_milliseconds_per_tick(); }

Context: STM32 HAL expects HAL_GetTick() to return a millisecond counter for timeouts and delays. A 32-bit millisecond counter overflows every \~49.7 days at 1ms tick.

Potential Bug: If the system tick is larger than 1ms (e.g., 10ms/tick), the multiplication can overflow faster, roughly every 4.97 days, causing HAL drivers (UART, I2C, SPI) to see incorrect time values.

And the fix is to Cast to 64-bit before multiplication to avoid intermediate overflow, then return as uint32_t. Ensures correct millisecond count regardless of tick size.

AI usage: yes 

Prompt used: what is i used more than one millisecond and less than i know that the reference manual say the initial is one milli

AI model: GPT-5 mini 

How AI was used: just predicting unusual behavior

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1144
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260317/997762c4/attachment.htm>