standby on stm32u375 not reaching low power state

[Geoffrey1]

I have no problem reaching a low power state with stop3.  All the Pull Up/Down registers are configured correctly.  However, simply changing the low power mode from STOP3 to STANDBY results in a 1.5mA current sink.  What could this be?  The debugger support is off in both cases.

[MM..1]

Try show more info primary current in STOP3? And i see you bare metal in next thread, Use LL examles STM32CubeU3/Projects/NUCLEO-U385RG-Q/Examples_LL/RTC/RTC_ExitStandbyWithWakeUpTimer_Init/Src/main.c at main · STMicroelectronics/STM32CubeU3 · GitHub

[Jason Miller234]

A 1.5 mA current in STANDBY usually means the MCU isn't entering true standby. Check wake-up sources, RTC, external peripherals, and verify your standby entry code. Sharing the MCU model and code will help identify the exact cause.

[Geoffrey1]

It’s an stm32u375.  I can see (with test pins) that it’s entering this code and I can see, via the Pull up/down that it’s definitely not transitioning to standby, but it’s definitely waiting in the wfi

 

Here’s the entry code (stm32u375). 

 

 tagDevicesDisableWakeupSources();
  tagPowerClearWakeFlags();
  DBGMCU->CR = 0;
  MODIFY_REG(PWR->CR1, PWR_CR1_LPMS, 4U);

  //tagPowerSelectStop3();

  SET_BIT(SCB->SCR, ((uint32_t)SCB_SCR_SLEEPDEEP_Msk));

  __DSB();
  __WFI();

 

[MM..1]

Maybe when your read reference manual (2800 pages) and next appnotes and docs, you can write bare code, but in real life dont ask here about your bare code miss. And after only maybe read basics, you get info , that 375 and 385 is same except encrytion engine.

[Geoffrey1]

That's a rather rude response.  You assume I haven't read the reference manual, I have, that I haven't read st hal, I have, or that I'm somehow unqualified to write "bare code", I'm not.   As usual, the st documentation leaves edge cases as an exercise to the reader.

 

I started with a basic question, why would stop3 work, and standby not.  Btw, I've used standby on the stm32l432 for years .  There is nothing evident in the st code or documentation that points to an obvious got you.  I only posted code in response to previous feedback.

 

 

[MM..1]

Test example https://github.com/STMicroelectronics/STM32CubeU3/blob/main/Projects/NUCLEO-U385RG-Q/Examples_LL/RTC/RTC_ExitStandbyWithWakeUpTimer_Init/Src/main.c

 

[Geoffrey1]

I'm still looking for insight.  Given code that successfully enters stop3, but fails to enter standby,  what are possible issues to explore,  simply throwing example code my direction doesn't provide any insight since the method is the same - cleat wakeup flags, clear pending interrupts, set lpms, set the deep sleep bit,  wfi.

[Piranha]

And their examples are broken anyway… You won't get real solutions or even a decent insight from ST's support or other especially gifted ones. Instead read this topic very carefully:

And as you can see by the dates in that and other topics - no, they will not fix neither the documentation, nor the code. The only thing they care is closing the topics and ignoring the issues.

[Geoffrey1]

Piranha,  thanks for your reply.  Sadly no joy.  I can tell that the stm32u375 is executing and staying in wfi, but at huge power. Since the pull up and pull down work properly in stop3,  I have to conclude there is an undocumented bug/feature in this part.  I've abandoned this effort and am using stop3 by emulating standby with a reset flag in the backup registers and system reset.  A separate issue made stop3 direct use untenable because flash write fails after stop3. A pity that sr documentation is so sloppy.  They really need to hire writers who understand computer architecture and can read internal specs.  I say this as one who co-led the joint st/hp effort that created the st2xx family of vliw processors.

[waclawek.jan]

​@Piranha mentioned it in his article he linked to above, and also you mention it in the OP, but did you verify that DBGMCU_CR.DBG_STANDBY = 1 and how?

[EDIT] OK I see you write DBGMCU_CR to zero explicitly; I’d insert a bunch of NOPs and perform a readback, if there’s a chance that it was nonzero previously. [/EDIT]

You may also want to try to exercise the ST example on the Nucleo board and if that does work, try to find the difference(s).

Also, you may want to experiment with a minimal example, avoiding any other code and allowing it to post in its entirety.

JW

[Geoffrey1]

I finally isolated the issue -- it had to do with the interaction between the spi device and the the standby hardware.  Even though spi was disabled.  The final incantation that pushed things into working:

 

RCC->APB2RSTR |= RCC_APB2RSTR_SPI1RST;

RCC->APB2RSTR &= ~RCC_APB2RSTR_SPI1RST;

 

It would be super helpful if st actually documented the standby functionality properly -- for example enumerating the things that could prevent standby.   I do think it’s a bug that the default behavior is to noiselessly enter a high-power state.