STM32u5 does not enter stop mode 2 reliably / wakes up too early

[Meixner]

I am trying to enter stop mode 2 and have it woken up by LPTIM1. Now my problem is that stop mode is not entered reliably (or it wakes up too early which I cannot differentiate). The probability stop mode is entered seems to depend on LPTIM1 configuration. I have checked the pending IRQs in NVIC after wake-up, but none is set when it does not enter stop mode. So I wonder why stop mode 2 was not entered or left too early.

This is what I am doing:

   uint32_t irqpend[16];

   if(timeout_sec>=0) {
      vfLPTimerAlloc(1);
      vfLPTimerSetDuration(1,LPTIMER_CLK_LSE,timeout_sec*1000,true,true);
   }

   /* Enter a critical section but don't use the taskENTER_CRITICAL()
    * method as that will mask interrupts that should exit sleep mode. */
   __asm volatile ( "cpsid i" ::: "memory" );
   __asm volatile ( "dsb" );
   __asm volatile ( "isb" );

   if(timeout_sec>=0) {
      __HAL_RCC_LPTIM1_CLKAM_ENABLE(); // enable autonomous mode
      vfLPTimerEnable(1,0);
   }

   HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);

   if(timeout_sec>=0) vfLPTimerDisable(1);

   SECURE_SystemClock_Config(); // call secure side of TrustZone to restore clock settings

   for(int z=0;z<16;z++) irqpend[z]=NVIC->ISPR[z];

   /* Re-enable interrupts to allow the interrupt that brought the MCU
    * out of sleep mode to execute immediately.  See comments above
    * the cpsid instruction above. */
   __asm volatile ( "cpsie i" ::: "memory" );
   __asm volatile ( "dsb" );
   __asm volatile ( "isb" );

   if(timeout_sec>=0) vfLPTimerFree(1);
   for(int z=0;z<16;z++) fprintf(stderr,"ISPR[%d]=%08X\n",z,irqpend[z]);

The device has TrustZone enabled.

Shouldn't one of the IRQs be pending when HAL_PWREx_EnterSTOP2Mode() returns? I see an IRQ set when stop mode worked, but none when it did not work.
Why does it work sometimes and sometimes not?
And why does the probability depend on LPTIM1 configuration when there is no IRQ triggered? The higher the timeout, the higher is the probability that it does not work.

And the most important question: How can this be fixed?

[Meixner]

Repeating the call to HAL_PWREx_EnterSTOP2Mode() when all IRQs are 0 does not help.

[Meixner]

Example HAL settings of LPTIM1 when entering stop mode 2 fails reliably:

{Instance = 0x46004400, Init = {Clock = {Source = 0, Prescaler = 3584}, UltraLowPowerClock = {Polarity = 0, SampleTime = 0}, Trigger = {Source = 65535, ActiveEdge = 0, SampleTime = 0}, Period = 65361, UpdateMode = 0, CounterSource = 0, Input1Source = 0, Input2Source = 0, RepetitionCounter = 234}, Channel = HAL_LPTIM_ACTIVE_CHANNEL_CLEARED, hdma = {0x0, 0x0, 0x0}, Status = HAL_OK, Lock = HAL_UNLOCKED, State = HAL_LPTIM_STATE_RESET, ChannelState = {HAL_LPTIM_CHANNEL_STATE_RESET, HAL_LPTIM_CHANNEL_STATE_RESET}}

[Bubbles]

Hi @Meixner,

on this forum it's not always a good idea to reply to your own question. At least before someone else reacts. Questions without reply are more visible for us.

I haven't found a solution for you, I have just some tips. If you have means to measure the device power consumption, for example using X-nucleo-LPM01 (cubemonitor-power), you can observe if STOP2 was actually entered and for how long.

You can also try to divide the problem by first using some simpler methos for wakeup (EXTI on GPIO) and then observe functionality of the LPTIMER using another GPIO output. After having the simple parts confirmed working, combine them.

BR,

J

[Meixner]

When it does not enter Stop Mode, it returns immediately.

When it enters Stop Mode, power consumption is reduced significantly, which I can measure on the power supply.

I have already tested waking up via GPIO. That does work and I see the pending IRQ as expected.

LPTIM has also been tested standalone and was working.

The problem is entering Stop Mode with LPTIM1 as wake up source. This does not work reliably with LPTIM in one-shot mode and rather long timeout.

I have already considered the errata for "Device may remain stuck in LPTIM interrupt when entering Stop mode" but also without success.