STM32H562 SysTick 2ms instead of 1ms

[PavelSvihalek]

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?

[Tesla DeLorean]

So print out the clocking the part thinks it has.

Unpack the RCC registers

Export the internal clock via PA8 / MCO

[PavelSvihalek]

Here are registers:

And PA8:

 

clocks

And main clock selection:

 

 

 

[Tesla DeLorean]

0x7A11 * 8 ~ 249992 seems Ok

Are you TOGGLING a GPIO in Systick_Handler() ?

[PavelSvihalek]

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.

[waclawek.jan]

> 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

[PavelSvihalek]

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.

[waclawek.jan]

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