2024-12-13 10:32 AM
I *think* that the check on line 7 below is to make sure that wait doesn't overflow when adding uwTickFreq. This isn't guaranteed to work unless uwTickFreq is 1.
__weak void HAL_Delay(uint32_t Delay)
{
uint32_t tickstart = HAL_GetTick();
uint32_t wait = Delay;
/* Add a period to guaranty minimum wait */
if (wait < HAL_MAX_DELAY)
{
wait += (uint32_t)uwTickFreq;
}
while ((HAL_GetTick() - tickstart) < wait)
{
}
}
You can do the following instead to catch the potential overflow (forgot a cast of uwTickFreq and I don't see a way to edit the code).
__weak void HAL_Delay(uint32_t Delay)
{
uint32_t tickstart = HAL_GetTick();
uint32_t wait = Delay;
/* Add a period to guaranty minimum wait */
if (wait <= HAL_MAX_DELAY - uwTickFreq)
{
wait += (uint32_t)uwTickFreq;
}
while ((HAL_GetTick() - tickstart) < wait)
{
}
}
2024-12-13 10:39 AM - edited 2024-12-13 10:39 AM
ST here miss as is writed maximaly. Realy logic is use instead
HAL_MAX_DELAY
HAL_MIN_DELAY
2024-12-13 12:51 PM
Valid bug report. Unlikely to affect anyone. Not many people are using HAL_Delay to wait 49.7 days.