2024-12-09 08:42 AM
I have setted:
SYSCLK: 250 MHz
HCLK: 250 MHz
As a SysTick source I tried: HCLK, HCLK/8, LSI
STM32Cube FW_H5 V1.4.0
I'm getting 2ms instead of 1ms in any configuration. Any idea how to fix it?
Solved! Go to Solution.
2024-12-11 12:20 AM
I try to insert toggle command into interrupt.. 1ms was OK.
So problem is at implementation of "HAL_Delay(T)" function - T is (T+1).
When I try HAL_Delay(2), time is 3ms.
ST insert this code into HalDelay function:
/* Add a freq to guarantee minimum wait */
if (wait < HAL_MAX_DELAY)
{
wait += (uint32_t)(uwTickFreq);
}
and this causes, the delay time is 1ms longer than I expect.
I understand why they insert this code there, but it's limiting.
Thanks for the guidance, I didn't expect this change in the HAL library.
2024-12-09 09:46 AM
So print out the clocking the part thinks it has.
Unpack the RCC registers
Export the internal clock via PA8 / MCO
2024-12-09 11:31 PM
Here are registers:
And PA8:
And main clock selection:
2024-12-10 02:03 PM
0x7A11 * 8 ~ 249992 seems Ok
Are you TOGGLING a GPIO in Systick_Handler() ?
2024-12-10 11:31 PM
Yes. This is my test code:
HAL_Delay(1);
HAL_GPIO_TogglePin(WM_BUS_CS_GPIO_Port, WM_BUS_CS_Pin);
HAL_Delay(1);
HAL_GPIO_TogglePin(WM_BUS_CS_GPIO_Port, WM_BUS_CS_Pin);
HAL_Delay(1);
HAL_GPIO_TogglePin(WM_BUS_CS_GPIO_Port, WM_BUS_CS_Pin);
HAL_Delay(1);
HAL_GPIO_TogglePin(WM_BUS_CS_GPIO_Port, WM_BUS_CS_Pin);
2024-12-10 11:35 PM
(It is not in the interrupt, but for this testing case it is same)
2024-12-11 12:20 AM
I try to insert toggle command into interrupt.. 1ms was OK.
So problem is at implementation of "HAL_Delay(T)" function - T is (T+1).
When I try HAL_Delay(2), time is 3ms.
ST insert this code into HalDelay function:
/* Add a freq to guarantee minimum wait */
if (wait < HAL_MAX_DELAY)
{
wait += (uint32_t)(uwTickFreq);
}
and this causes, the delay time is 1ms longer than I expect.
I understand why they insert this code there, but it's limiting.
Thanks for the guidance, I didn't expect this change in the HAL library.
2024-12-11 12:29 AM
> but for this testing case it is same
No, it is not.
HAL_Delay(N) provides a *minimum* N-ms delay, and with 1ms granularity of the underlying timer this means, that (with no external intervention like higher-priority interrupt) it provides delay of 1..2ms. And, with the code you wrote, guarantees, that (except for the first period) it will always yield close to 2ms.
Cube/HAL is open source, you can/should look up how things are actually implemented.
JW
2024-12-11 12:35 AM
So why isn't the function called HalMinimumDelay()?.. (That's just a rhetorical question)
In older implementations, this function was implemented as I previously expected.
2024-12-11 03:57 AM
Loopdelays which don't provide *minimum* delay (i.e. where there's a chance that the delay they provide is less than what's requested) are fundamentally flawed and should never have existed.
I don't use Cube/HAL and never did.
JW