standby on the stm32u375 -- a cautionary tail

[Geoffrey1]

I was finding non-deterministic behavior entering standby -- small code changes unrelated to the standby code or devices seemed to prevent standby.  Many hours of debugging later using a joulescope and claude automation, the following fixed the problem -- declare the standby code as noinline (by default, my builds inline small funcitons)

 

void __attribute__((noinline)) enter_standby_mode(void)

 

Also, an attribute to not optimize works as well.   It did not appear that the generated assembly for the standby code changed, but what did change, due to inlining, is the code alignment.  This suggests, but doesn’t confirm, that the fetch pipeline can impact the ability to enter standby on this part.  This was never an issue on the stm32l432.

[jiangfan]

Yes, this is possible. Even if the standby entry assembly itself is unchanged, inlining can change code alignment and surrounding instruction timing, which may affect a timing-sensitive low-power entry sequence. The fact that noinline or nooptimize fixes it suggests the issue is likely related to code layout or a race condition around entering Standby rather than a functional change in the standby routine itself. This can be device-family dependent, which could explain why it was not seen on STM32L432.

To make standby entry more robust:

1. Keep the standby entry function isolated

   • noinline is a good idea.

2. Minimize code before the entry

   • avoid extra logging, conditionals, and heavy compiler optimization around the sequence.

3. Use explicit barriers if appropriate

   • for example, ensure memory/system state is fully committed before the sleep/standby instruction.

4. Check for pending interrupts and wake sources

   • a race with an interrupt can cause exactly this kind of non-determinism.

5. Test with different optimization levels

   • if behavior changes with -O0/-O2/-Os, that is a strong sign of timing/layout sensitivity.

NOTE: reviewed answer mostly from AI