1. Distinguish stopped execution from retained state
State retention and continuing execution describe different capabilities. ST's AN5213 discussion gives STM32L5 Stop modes SRAM and peripheral-retention capability while describing the stopping of high-speed oscillators. Retaining information therefore should not be interpreted as the CPU continuing its ordinary processing. The preserved state and the activity taking place during the mode need separate descriptions in the application requirement.
The distinction also applies to peripherals. A retained peripheral state can concern information that remains available after the mode, while an active peripheral function must have the resources needed to operate during it. The word retained does not, by itself, establish that every peripheral continues observing inputs, transferring data or performing its normal work throughout the low-power period.
Frame the requirement around the state that must survive and the work, if any, that must continue. Those are different questions even when they concern the same functional block. AN5213 supplies a named STM32L5 context for understanding that separation; it does not describe the current configuration of an application or establish the retention and execution behaviour of every MCU marketed as low power.
2. Compare default and optional Standby retention
Standby needs its own retention description rather than inheriting the Stop statement. AN5213 says SRAM content is lost by default in Standby. It separately identifies an option to preserve all or part of SRAM2, with an additional current-consumption implication. The default state and the optional retention capability therefore should remain distinct when specifying what application information must survive.
The option is described for SRAM2 in this STM32L5 discussion. It should not become a statement that every SRAM bank or every piece of application state survives Standby. A general requirement to retain memory leaves the actual information and memory context unspecified. The useful comparison identifies the needed retained state and asks whether the documented option addresses that particular requirement.
An optional feature also differs from evidence that an application uses it. The presence of a retention capability in the note does not establish the selected operating configuration. Keep the manufacturer's default description, optional capability and application's intended requirement distinguishable. This preserves the engineering decision without assigning a bank-level guarantee from an unread table, prescribing a configuration sequence or quoting a current penalty.
3. Keep wake-capable clock and peripheral paths distinct
Wake-capable activity depends on the resources that remain available in the selected mode. AN5213 distinguishes stopped high-speed oscillators from low-speed clocks that can remain active in Stop. Its prose also describes peripherals using a clock when needed to recognize particular events. That is a mode-dependent operational capability, separate from preserving arbitrary peripheral contents for later use.
The note's qualifying text includes communication-related wake events, such as reception or address recognition, within its stated Stop context. This helps define what the application needs to detect while ordinary execution is stopped. A stored register image alone cannot demonstrate that an event-detection path has the clock and peripheral availability required to perform that recognition during the mode.
Specify the required event and the mode in which it must be recognized, alongside the separate state-retention requirement. This keeps the functional chain understandable without choosing a clock source, physical input or interrupt configuration. A documented wake-capable function is not a universal statement that all peripherals remain operational, and it does not prove that the board or firmware has enabled the necessary path.
4. Separate Shutdown and restart obligations
Shutdown introduces a different power context. AN5213 describes the internal voltage regulators and voltage power monitoring as switched off, while identifying limited wake functions and an RTC context using the external low-speed oscillator. Those surviving functions should not be expanded into a promise that the rest of the MCU behaves as it did in Stop or Standby.
The distinction matters when defining the state expected after wake. Information required to survive must be identified separately from information the application can reconstruct. The note also qualifies I/O configuration around leaving Shutdown, showing why a description of a function during the mode need not describe what remains configured afterwards. Mode residence and the state following exit are related but different parts of the requirement.
Complete the low-power requirement through retained information, activity needed during the mode, the permitted wake event and the responsibilities after exit. This is a functional comparison within the named STM32L5 note, rather than a firmware recipe. It supplies no mode-current figure, wake timing, register procedure or tested restart result. Keeping these responsibilities separate makes the intended retention requirement clearer than selecting a candidate from a single sleep-feature headline.
Sources and further reading
ST AN5213 Rev. 2, STM32L5 prose on physical pages 9–10 and qualifying text on page 12. No mode-current or timing numbers, table-derived bank guarantees, pin map or register procedure is used.