LPTIM, wrong IRQ triggering frequency in continous mode.

[GiuseppeB]

I'm using the STM32U031C8U6 with STM32CubeIDE 1.19.0 and can't figure out how LPTIM1 works.

I created a new project and enabled LPTIM1 in Device Configuration Tools (Mode: Counts internal clock events). In the NVIC Interrupt table tab, I enabled the interrupt.
In Clock Configuration, I enabled LSE clock (32768 kHz) and selected it on the LTPIM1 Clock Mux.

I generated the code and modified the main() function as follows:

int main(void)
{
 HAL_Init();
 SystemClock_Config();
 MX_GPIO_Init();
 MX_LPTIM1_Init();

 HAL_LPTIM_TimeOut_Start_IT(&hlptim1, 320);

 while (1)
 {
	HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);
 }
}

HAL_LPTIM_TimeOut_Start_IT() enables the timeout function, sets compare register CCR1 = 320 and starts the timer in continuous mode.

I expected the HAL_LPTIM_CompareMatchCallback callback to be called every 10 ms (320 / 32768 kHz), waking up the micro.

This callback is actually triggered every 2 seconds according the value of the ARR register (by default, 65535).
I verified that the frequency with which the callback is called depends on the ARR register by trying different values.

Can anyone explain to me why the HAL_LPTIM_CompareMatchCallback() isn't called when the CNT == CCR1?
And why is it called when CNT == ARR? In this case I would have expected the triggering of HAL_LPTIM_AutoReloadMatchCallback().

Thank you in advance,
G.

[TDK]

There is a single counter per timer that counts from 0 to ARR. If you want to change the timer update frequency, change ARR, not CCRx.

HAL_LPTIM_CompareMatchCallback is called when CNT = CCRx.

[GiuseppeB]

I understood what my mistake was: inside HAL_LPTIM_CompareMatchCallback I did not reset the counter so this is actually triggeed with the frequency depending on ARR.

Thank you,

G.

[bmckenney]

You didn't show your callback function, but I'm guessing it doesn't take any action.

I think the notion behind this mechanism is that a timeout (callback) is a significant event, and the callback will take some action, e.g. report the timeout, then reset the counter (COUNTRST, e.g.) for the next timeout. Otherwise (in the absence of a trigger event) the counter will just keep counting until it wraps at ARR, yielding a callback period of =ARR.

[GiuseppeB]

I just found the problem a little while ago. Thanks a lot anyway,

G.