cancel
Showing results for 
Search instead for 
Did you mean: 

LPTIM1 with LSE clock gets stuck waiting for ARROK flag

Errorr__
Associate III

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Errorr__
Associate III

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!

View solution in original post

8 REPLIES 8
waclawek.jan
Super User

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

Saket_Om
ST Employee

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
Gyessine
ST Employee

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.

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__
Associate III

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!

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

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

waclawek.jan
Super User

I see, thanks for this piece of information.

JW