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.
_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs
