STM32WL33CC DEEPSTOP power consumption
Support request: STM32WL33CC — DEEPSTOP average current rises well above datasheet spec, even within a single uninterrupted dwell
Part / package
STM32WL33CC (custom board, not a Nucleo/eval board).
Summary
On our custom board, DEEPSTOP average current starts near the expected low-µA range on entry but climbs over tens of seconds to a plateau of roughly 360–390 µA — two to three orders of magnitude above the datasheet's Table 13 "Current consumption in DEEPSTOP mode" figures (≈1.2–2.1 µA ICORE across all listed LSI/LSE/RTC/IWDG/LPUART configurations).
This is reproducible, happens within a single uninterrupted DEEPSTOP dwell (i.e. it is not an artifact of repeated entry/exit cycling), and we have ruled out every peripheral, sensor, and firmware-level cause we can identify. We'd like ST's input on whether this is a known/expected behavior of the DEEPSTOP power architecture (e.g. an internal analog settling time not captured in the static spec table) or points to a board- or configuration-level issue we've missed.
Observed behavior (measured with a Joulescope JS110, powered from a bench lab supply — no battery involved)
- Entering SHUTDOWN mode gives a clean, stable 33–34 µA baseline (this is understood to be external, non-STM32WL33 board current — a magnetometer and accelerometer remain active in this state).
- Entering DEEPSTOP starts at a clean 20–30 µA baseline, then climbs steadily over roughly 30–60 seconds to a ~360–390 µA plateau.
- The climb is visible both across many short (~1 s) DEEPSTOP entry/exit cycles and within a single uninterrupted DEEPSTOP dwell of 60 s with no intervening wake — ruling out any per-cycle re-entry/reconfiguration effect.
- The elevated current is not simply "stuck" — it resets cleanly back to the ~20–30 µA baseline only after a genuine SHUTDOWN-mode wake (full reset-equivalent boot), and climbs again identically regardless of which DEEPSTOP-cycling path triggered it.
- Active (RUN-mode) pulse width between DEEPSTOP dwells was confirmed constant (~16 ms) via Joulescope zoom, ruling out growing per-cycle CPU work as a contributor.
What has been ruled out
We isolated each of the following individually via compile-time test builds, re-flashed and re-measured after each change, then reverted before testing the next:
- I2C bus and both external sensors (IIS2MDC magnetometer, IIS2DULPX accelerometer): disabled all I2C traffic on every wake (including the I2C peripheral's own re-init), forced the magnetometer into idle mode as the last command it ever receives (rather than leaving it in its default Continuous-mode/10 Hz configuration), and removed their DRDY/INT lines from every DEEPSTOP wake-source arming register. Current creep unchanged.
- MR_SUBG (sub-GHz radio) entirely: forced RCC_APB2ENR_MRSUBGEN off before every DEEPSTOP entry (never re-enabled for the duration of the test) and bypassed our own LSI-frequency calibration routine (which otherwise depends on MR_SUBG) by assuming a fixed, previously-measured LSI value instead. Current creep unchanged.
- RTC wakeup-timer per-cycle reprogramming: our firmware normally disables/reprograms/re-enables the RTC wakeup timer (WUTE/WUTR/WUCKSEL) on every DEEPSTOP entry, even when the requested period is unchanged. We patched this to skip the reprogram and let the wakeup timer free-run/auto-reload across cycles when the period is constant. Current creep unchanged.
- PWR_CR5.SMPSLPOPEN polarity: tested both settings (VFBSD tied to VDDSD vs. floating during the DEEPSTOP SMPS "STOP" sub-state). No measurable difference either way.
- Cycling frequency itself: to separate "how often DEEPSTOP is entered" from "how long DEEPSTOP has been running," we forced a single uninterrupted 60 s DEEPSTOP dwell (watchdog temporarily disabled for this test only) instead of our normal ~1 s cadence. The current still climbed to the same ~360 µA plateau within that one dwell — this was the most decisive result, and rules out repeated Run↔Stop toggling of the SMPS/VDD12i domain as the mechanism.
- GPIO retention/ODR glitch: found and fixed an unrelated real bug (output pins glitching low for one cycle after DEEPSTOP wake, before GPIORET release) — confirmed no effect on the current creep either way.
- CPU context save/restore assembly: reviewed the WFI/context-save routine; it only touches the Cortex-M0+ register stack via a RAM-addressed pointer, no peripheral register accesses.
- Errata sheet (ES0612): reviewed; the only DEEPSTOP-current-adjacent erratum found (2.2.9, nonbonded GPIOs) applies to the VFQFPN32 package, not our part's package, so does not appear applicable.
- Battery passivation: not applicable — board is powered from a bench lab supply (GPR30160) for all measurements, no battery in the current path.
We have not been able to test SMPS bypass directly: our board's VFBSD pin is wired to the SMPS's own L/C network (per our schematic) for SMPS-active operation, not to VDD or an external supply as required by the datasheet's "No SMPS" configuration, so PWR_CR5.NOSMPS is not a valid configuration on this hardware without a rework. We have not attempted SMPS Bypass-On-The-Fly (NOSMPS_BOF) yet.
Configuration during the decisive (single-dwell) test
- No I2C activity, both external sensors idle, MR_SUBG powered down entirely (see above) — the only wake source armed was the RTC wakeup timer.
- PWR_CR5.SMPSLPOPEN = 0 (VFBSD tied to VDDSD during STOP).
- LSI-sourced RTC wakeup timer, ~35070 Hz measured LSI frequency (this board's next hardware revision will use a properly wired LSE crystal instead of relying on LSI).
- IWDG temporarily disabled for this one test only (re-enabled immediately afterward).
Questions for ST
- Is a multi-second-to-a-minute current ramp from the low-µA baseline up to ~360–390 µA within a single DEEPSTOP dwell expected/known behavior of any internal analog block (SMPS "STOP" sub-state bias, Main LDO, VCAP settling, GPIORET retention circuitry, etc.), and if so is it documented anywhere beyond the static Table 13 figures?
- Is there a known erratum covering this that isn't captured in ES0612 as we have it, or a required configuration/sequencing step we may have missed for sustained DEEPSTOP operation?
- Given our board's VFBSD wiring (tied to the SMPS L/C network, not to VDD), is SMPS Bypass-On-The-Fly (NOSMPS_BOF) expected to work correctly as a way to rule out the SMPS specifically, or does it have the same board-wiring prerequisite as plain NOSMPS?
Happy to provide register dumps, oscilloscope captures (VCAP/VFBSD nodes), or a minimal reproduction firmware image on request.
