STM32H573 LPTIM4 auto-reload callback: first measured interval is ~743 ms, then stable at ~1010 ms

[ignazio]

Hello,

I am working on an STM32H573-based project using STM32Cube HAL and ThreadX.

I configured LPTIM4 as an independent clock monitor. LPTIM4 uses LSI as clock source, with:

- LPTIM4 clock source: LSI
- LSI nominal frequency: 32 kHz
- LPTIM4 prescaler: DIV1
- LPTIM4 period / ARR: 32000
- LPTIM4 started with HAL_LPTIM_Counter_Start_IT(&hlptim4)

The goal is to get one LPTIM4 auto-reload match interrupt approximately every 1 second.

Inside HAL_LPTIM_AutoReloadMatchCallback(), I compare the elapsed HAL tick time between two LPTIM4 auto-reload callbacks:

uint32_t now = HAL_GetTick();
uint32_t delta = now - previousTick;

if (!initialized)
{
previousTick = now;
initialized = true;
return;
}

if ((delta < 900U) || (delta > 1100U))
{
// clock drift error
}

previousTick = now;

In my project HAL_GetTick() is not driven by SysTick. The HAL time base is TIM1, configured to call HAL_IncTick() every 1 ms.

What I observe is that the first real check, i.e. the second LPTIM4 callback, reports a wrong short interval. After that, all following intervals are stable and correct.

Example log:

[0000000980] [IRQ] CLK monitoring started at tick 980
[0000001723] [IRQ] System Clock drift detected! Expected ~1000ms, got 743ms
[0000001723] [IRQ] CLK tick now=1723 previous=980 delta=743
[0000002733] [IRQ] CLK tick now=2733 previous=1723 delta=1010
[0000003743] [IRQ] CLK tick now=3743 previous=2733 delta=1010
[0000004753] [IRQ] CLK tick now=4753 previous=3743 delta=1010
[0000005762] [IRQ] CLK tick now=5762 previous=4753 delta=1009
[0000006772] [IRQ] CLK tick now=6772 previous=5762 delta=1010

So the issue seems to happen only once, at the first measured interval. If LPTIM4 or LSI were really running too fast, I would expect all intervals to be around 743 ms, but instead the following callbacks are consistently around 1009-1010 ms.

The first LPTIM4 callback happens during the end of sensor initialization / transition to ThreadX startup. After that, the system runs normally.

My questions are:

1. Can the first/second LPTIM auto-reload match after HAL_LPTIM_Counter_Start_IT() be affected by ARR update, pending flags, synchronization, or startup behavior?
2. Is it possible that HAL_GetTick(), driven by TIM1, loses ticks during early startup or during some HAL/middleware operation, while LPTIM4 continues running from LSI?
3. Is comparing LPTIM4 against HAL_GetTick() a valid approach for this kind of clock monitoring, or should I use another reference such as DWT cycle counter, direct timer capture, or a hardware output measurement?
4. What is the recommended way to ignore only the startup transient without hiding a real clock drift?

Any suggestion on how to distinguish between an early LPTIM event and a lost HAL tick would be very helpful.

Thanks.

[TDK]

1. Can the first/second LPTIM auto-reload match after HAL_LPTIM_Counter_Start_IT() be affected by ARR update, pending flags, synchronization, or startup behavior?

LSI take a bit to stabilize.

2. Is it possible that HAL_GetTick(), driven by TIM1, loses ticks during early startup or during some HAL/middleware operation, while LPTIM4 continues running from LSI?

No, TIM1 won't lose ticks unless you disable interrupts or otherwise prevent the interrupt from happening.

3. Is comparing LPTIM4 against HAL_GetTick() a valid approach for this kind of clock monitoring, or should I use another reference such as DWT cycle counter, direct timer capture, or a hardware output measurement?

DWT, TIM1, and SysTick all use the same system timer, provided you haven't remapped TIM1 to use something else. So using any of them is equivalent. Some chips have a CSS to detect clock issues.

4. What is the recommended way to ignore only the startup transient without hiding a real clock drift?

If (tick < 5) {

ignore

} else {

don't ignore

}