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.