Skip to main content
Associate II
February 4, 2026
Solved

LPTIM1 with LSE clock gets stuck waiting for ARROK flag

  • February 4, 2026
  • 5 replies
  • 295 views

Hi all,
I’m running into an issue with LPTIM1 when using LSE as the clock source. The exact same configuration works perfectly when I use LSI or PCLK, but with LSE the code gets stuck waiting for the ARROK flag after writing ARR.
The code blocks forever at:
while (!LL_LPTIM_IsActiveFlag_ARROK(LPTIM1)) {} 
So it looks like the ARR register update is never acknowledged when LSE is the clock.
Important notes

  • LSE is definitely running — it’s already used elsewhere in the system without issues.
  • We are looking for low power application
  • we using STM32U073CBT6


Clock configuration

LL_RCC_SetLPTIMClockSource(LL_RCC_LPTIM1_CLKSOURCE_LSE); LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_LPTIM1); LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOC);
NVIC_SetPriority(TIM6_DAC_LPTIM1_IRQn, NVIC_EncodePriority(NVIC_GetPriorityGrouping(), 3, 0));
NVIC_EnableIRQ(TIM6_DAC_LPTIM1_IRQn);


LPTIM configuration

/* Make sure timer is disabled before config */
LL_LPTIM_Disable(LPTIM1);
/* Select clock & prescaler FIRST */
LL_LPTIM_SetClockSource(LPTIM1, LL_LPTIM_CLK_SOURCE_INTERNAL);
LL_LPTIM_SetPrescaler(LPTIM1, LL_LPTIM_PRESCALER_DIV1);
LL_LPTIM_SetUpdateMode(LPTIM1, LL_LPTIM_UPDATE_MODE_IMMEDIATE); LL_LPTIM_SetCounterMode(LPTIM1, LL_LPTIM_COUNTER_MODE_INTERNAL);
/* Enable peripheral */
LL_LPTIM_Enable(LPTIM1);
/* Enable interrupt */
LL_LPTIM_EnableIT_ARRM(LPTIM1);
/* Set ARR and wait until it is taken into account */
LL_LPTIM_ClearFlag_ARROK(LPTIM1);
LL_LPTIM_SetAutoReload(LPTIM1, 31199);
while (!LL_LPTIM_IsActiveFlag_ARROK(LPTIM1)) {}
/* Start counter */
LL_LPTIM_StartCounter(LPTIM1, LL_LPTIM_OPERATING_MODE_CONTINUOUS);


What I expected
ARR should be written successfully and ARROK should assert, just like when using LSI or PCLK.
What actually happens
With LSE as LPTIM clock, ARROK never sets and the code stalls.

Best answer by Errorr__

Hi all,

STM32CubeMX-generated clock initialization code, the HAL and LL versions are not equivalent in how they configure LSE distribution.

  • In the STM32CubeMX-generated HAL clock initialization, LSESYSEN (LSE propagation to system) is enabled.
  • In the STM32CubeMX-generated LL clock initialization, LSESYSEN is not enabled.

As a result:
With the HAL-generated RCC init, LSE is not only started but also propagated into the system clock tree, allowing peripherals such as LPTIM (when selecting LSE) to receive the clock correctly, even after a true Power-On Reset (POR).

With the LL-generated RCC init, LSE may be running in the backup domain, but because LSESYSEN is not set in the STM32CubeMX-generated LL code, the clock is not distributed beyond the backup domain. Consequently, LPTIM does not receive the LSE clock after a POR.

After I manually enabled the LSESYSEN bit, LPTIM with LSE worked properly!

5 replies

waclawek.jan
Super User
February 4, 2026

Read out and check/post content of RCC_BDCR, RCC_CCIPR and LPTIM registers.

Is this issue LPTIM1-specific, or does it occur also on LPTIM2/3?

JW

Technical Moderator
February 4, 2026

Hello @Errorr__ 

Did the LSE clock enabled? 

LL_RCC_LSE_Enable()
"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Saket_Om"
Technical Moderator
February 5, 2026

Hello @Errorr__ 
If you still have this issue,
I have a project with similar requirements. that runs on a Nucleo U083RC board 
LPTIM1 (at LL level) is clocked by the LSE.
You can use this project as a reference to identify the root cause of your problem.
The project is configured to toggle the PC3 pin every ~one second.
PSC is set to 2, and ARR is set to 16000.

Gyessine_0-1770280650090.png

Here is the code sequence that you need to implement to start the timer

 /* USER CODE BEGIN LPTIM1_Init 2 */
 LL_LPTIM_Enable(LPTIM1);

 
 LL_LPTIM_ClearFLAG_ARRM(LPTIM1);
 LL_LPTIM_EnableIT_ARRM(LPTIM1);

 
 LL_LPTIM_StartCounter(LPTIM1, LL_LPTIM_OPERATING_MODE_CONTINUOUS);
 /* USER CODE END LPTIM1_Init 2 */

I hope this reply helps resolve your issue. If it does, please accept it as the solution so that other community members can use it as a reference.

Gyessine

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Errorr__Author
Associate II
February 9, 2026
Thanks again for the reference project

I observed something interesting when comparing behavior between HAL and LL RCC initialization, even though both projects use STM32CubeMX-generated code.

What I’m seeing

  • When RCC is initialized using the HAL-generated code, LPTIM works correctly with LSE even after a Power-On Reset (POR).
  • When I switch to the LL-generated RCC code (from CubeMX, not handwritten), LPTIM stops working after a POR.
  • If I first flash the version with HAL RCC init, then reflash the LL version without removing power, LPTIM continues to work.
  • But after a true POR, LPTIM no longer runs.
Errorr__AuthorBest answer
Associate II
February 10, 2026

Hi all,

STM32CubeMX-generated clock initialization code, the HAL and LL versions are not equivalent in how they configure LSE distribution.

  • In the STM32CubeMX-generated HAL clock initialization, LSESYSEN (LSE propagation to system) is enabled.
  • In the STM32CubeMX-generated LL clock initialization, LSESYSEN is not enabled.

As a result:
With the HAL-generated RCC init, LSE is not only started but also propagated into the system clock tree, allowing peripherals such as LPTIM (when selecting LSE) to receive the clock correctly, even after a true Power-On Reset (POR).

With the LL-generated RCC init, LSE may be running in the backup domain, but because LSESYSEN is not set in the STM32CubeMX-generated LL code, the clock is not distributed beyond the backup domain. Consequently, LPTIM does not receive the LSE clock after a POR.

After I manually enabled the LSESYSEN bit, LPTIM with LSE worked properly!

waclawek.jan
Super User
February 10, 2026

Nice catch. Thank you for coming back with the solution. 

However, in the initial post, you wrote: 

  • LSE is definitely running — it’s already used elsewhere in the system without issues.

so the  "elsewhere" did not require the LSESYSEN bit, then? What was it? 

JW

Errorr__Author
Associate II
February 10, 2026

It was being used by the RTC and for RTC we don't need the LSESYSEN according to the datasheet.

waclawek.jan
Super User
February 10, 2026

I see, thanks for this piece of information.

JW