Skip to main content
P
Peter
Associate
June 23, 2026
Solved

STM32WB5MMG (WB55) enters Stop2 (~7 µA) only after a debugger-mediated reset, never after a cold power-on reset (POR) — ~9 mA instead. All M4-vi

  • June 23, 2026
  • 1 reply
  • 39 views

Summary

On an STM32WB5MMG module (STEVAL-PROTEUS1), with BLE advertising active and the
application configured for Stop2 low-power operation, the device reaches the
expected Stop2 sleep current (p50 ~ 7 uA) ONLY after a debugger-mediated reset
(STM32CubeProgrammer: -c port=SWD mode=UR -rst).

After a cold power-on reset (POR) - removing and reapplying the supply, the real
deployment scenario - it draws a constant ~9 mA and never enters Stop2, even
though it otherwise runs completely normally (RTC cycle runs, BLE advertising
works, application data updates). This is 100% reproducible and deterministic.

Deployment-critical: in the field the customer inserts the battery (= POR) -> 9 mA
-> a 10 Ah cell lasts ~47 days instead of the intended multi-year lifetime.


Hardware / Software

- MCU/Module: STM32WB5MMG (STM32WB55 die) on STEVAL-PROTEUS1.
- Wireless stack: BLE_Stack_full V1.24.0.3 + FUS v2.2.0. First seen on V1.19.0 /
  FUS v1.2.0 and UNCHANGED after upgrading to V1.24.0 (the stack update did not fix it).
- RF config: Tx power 0 dBm, PHY 1 Mbit/s, channels 37/38/39, advertising via
  aci_gap_additional_beacon_start (rotating MAC), advertising interval 5 s.
- Low power: CubeWB tiny_lpm, CFG_LPM_SUPPORTED=1, Stop2 (LPMS=0b010),
  CFG_BLE_LS_SOURCE = LSE. Production build (CFG_DEBUGGER_SUPPORTED=0, DBGMCU
  low-power debug bits cleared at boot).
- Tools: STM32CubeIDE, STM32CubeProgrammer v2.22.0, ST-LINK/V3.
- Power/measurement: Nordic PPK2 in source mode @ 3.6 V (independent of ST-LINK;
  ST-LINK detached makes no difference - confirmed).


Reproduction (deterministic)

  Reset type                                  Result
  ------------------------------------------  ---------------------------------
  mode=UR -rst (debugger-mediated reset)      sleeps, p50 = 7 uA          (OK)
  Power-On Reset (supply off/on)              ~9 mA constant, no Stop2     (BUG)

Identical firmware image in both cases. The only difference is how the chip was
last reset.


What is already ruled out (measured on-target via SWD + compiled-in counters)

Application / LPM framework is NOT the cause:
- After POR all LPM gates are open: LPM_disabled = 0, LPM_disabled_forced = 0,
  CPU2_started = 1. The idle hook (UTIL_SEQ_Idle) is reached and calls
  UTIL_LPM_EnterLowPower() repeatedly. UTIL_LPM_SetStopMode(DISABLE) is never called.
- Wireless "FW running" ready event fires exactly once (no stack re-init loop).
- Disabling the sensor/measurement entirely -> still 9 mA after POR.
- Replacing the whole measurement layer with a pure software stub (no I2C/SPI/BSP/
  sensor access) -> still ~9 mA after POR (so the entire application layer is excluded).
- Disabling advertising (aci_gap_additional_beacon_start compiled out) -> still 9 mA.

CPU2 IS in deep-sleep after POR (so it is not "CPU2 refusing deep-sleep").
LL_PWR_IsActiveFlag_C2DS() counted in EnterLowPower:

  State              Current   lpm_calls   C2DS (CPU2 deep-sleep)
  -----------------  --------  ----------  ----------------------
  -rst (sleeps)      7 uA      37          35
  POR  (9 mA)        8.9 mA    84          80

Same ratio -> CPU2 reaches deep-sleep in both cases.

WFI entry rate identical: counters before/after __WFI in the Stop2 path:
-rst 34 / POR 30 over 42 s. So the M4 enters Stop2 the same way and is sitting in
WFI at the snapshot; the ~9 mA is drawn during a genuine Stop2, not in a busy loop.

Register snapshot at the Stop2 __WFI instant, POR vs -rst - all M4-visible Stop2
registers are bit-identical except the reset-cause flag:

  Register                  -rst (7 uA)     POR (9 mA)
  ------------------------  --------------  --------------
  SCB_SCR (SLEEPDEEP)       0x00000004      0x00000004
  PWR_CR1 (LPMS=Stop2)      0x00000302      0x00000302
  PWR_C2CR1                 0x00000004      0x00000004
  PWR_EXTSCR                0x00008200      0x00008200
  RCC_CR                    0x03030560      0x03030560
  RCC_CFGR                  0x00078005      0x00078005
  RCC_EXTCFGR               0x00130000      0x00130000
  RCC_CSR (reset cause)     0x04000000      0x0C000000
                            (PINRSTF)       (PINRSTF + BORRSTF)

RFWKPSEL = 0b00 in both cases (RF wake-up clock identical -> ES0394 2.3.1 excluded).

Self-heal via firmware reset does not work: NVIC_SystemReset (SYSRESETREQ) and an
IWDG reset both reset only the CPU1 subsystem; the device stays at 9 mA. A heal
counter in RTC->BKP1R proved the reset fired exactly once (no loop). Only the NRST
pin or a POR resets CPU2.

Errata checked (ES0394): 2.2.8 (EXTI line 48 / CDBGPWRUPREQ) - masked the line
before Stop2, no effect. 2.3.1 (RF wake-up clock) - excluded (RFWKPSEL=00). 2.2.17
(debug-in-stop) - debug bits off in the production build. No erratum matches 1:1.

SHCI: SHCI_C2_RADIO_AllowLowPower(BLE_IP, 1) called explicitly after APP_BLE_Init
-> no effect (default already applies).

Conclusion / hypothesis: since every M4-visible digital register is identical
between the 7 uA and the 9 mA case, and both cores are in deep-sleep, the extra
~9 mA must come from the RF / analog power management of the radio coprocessor
(CPU2) at cold start: after a cold POR the RF analog domain does not enter its
low-power state, whereas a debugger-mediated reset leaves CPU2 in a state where it
does. The only digital difference we can see is BORRSTF being set on POR.


Questions

1. Is there a known issue / expected behavior where the STM32WB radio (CPU2)
   RF/analog domain does NOT reach the expected Stop2 current after a cold POR,
   but does after a debugger-mediated reset (CPU2/debug stays "warm")?
2. Is there a required CPU2 / SHCI cold-start sequence or RF low-power handshake
   that differs between a cold POR and a warm/debug reset, that the application
   must perform explicitly?
3. Is there a software-only way to bring the CPU2 RF subsystem into the
   Stop2-capable state after POR (so we do not need an external GPIO->NRST hardware
   mod to pulse a real CPU2 reset)?
4. Can BORRSTF vs PINRSTF (reset cause) influence the CPU2 RF power-management
   initialization? Is there a recommended action when BORRSTF is set at boot?
5. Is any specific SHCI command or option (beyond SHCI_C2_RADIO_AllowLowPower)
   required at cold start to enable RF analog low-power in Stop2?


Attachments

- Register snapshot after -rst (7 uA, good).
- Register snapshot after POR (~9 mA, bug).
- Minimal reproducer project on request.

Best answer by Peter

SOLVED - and the STM32WB is innocent. Root cause is the ST1PS02 step-down
converter on the STEVAL-PROTEUS1 board, not the MCU, not CPU2, not the wireless
stack. I am correcting my own post so nobody chases the wrong lead.

What actually happens

The ST1PS02 (400 mA nano-quiescent buck, hysteretic control) can latch into a
high-loss operating state when it POWERS UP with VIN above its VOUT target
(3.3 V static default on this board: the D0-D2 voltage-select pins have 1 M
pull-ups - note they are bootstrapped to the converter's OWN output
ST1PS02_VOUT, so during the ramp the pins read low first and the target moves
2.6 V -> 3.3 V while the converter starts; EN is tied directly to VIN, so the
converter starts right on the battery-insertion edge). In that state the board
draws a broadband ~6-19 mA
(median ~10 mA) at the supply, regardless of what the MCU does. When it powers
up with VIN at or below the VOUT target, the state never occurs.

The decisive experiments

1. Supply-voltage A/B/A test (same firmware, same board, PPK2 source mode,
   power-on reset each time):
     POR at 3.0 V  ->  ~35 uA sleep   (OK)
     POR at 3.3 V  ->  ~39 uA sleep   (OK)
     POR at 3.45 V ->  ~9 mA, unstable
     POR at 3.6 V  ->  ~10.5 mA, stable  (the reported "bug")
     POR at 3.8 V  ->  ~10.4 mA, stable
     POR at 4.2 V  ->  ~10.1 mA, stable
   Fully reproducible in both directions. Note the 3.8/4.2 V points: the
   ENTIRE Li-Po range is affected, i.e. this also hits the standard
   STEVAL-PROTEUS1 kit configuration with the supplied 480 mAh Li-Po
   (consistent with a side observation: our kit battery drained from full to
   empty in ~37 h ~= 13 mA average while the MCU-side telemetry looked
   perfectly healthy).

2. Boot bisection: an eternal Stop2 loop as the VERY FIRST instruction in
   main() - before HAL_Init, clocks, GPIO, BSP, and with CPU2 never booted
   (C2BOOT never set, no BLE at all) - still shows ~14 mA after POR vs ~4 mA
   after a debugger reset. The excess current exists before the firmware
   executes anything and without the RF subsystem ever running. This
   definitively rules out CPU2 / RF-analog / wireless-stack causes.

3. No MCU-side action clears the state (each tested individually): NRST pin
   reset (CubeProgrammer -hardRst), software reset, RCC_APB3RSTR.RFRST pulse,
   hci_reset, flash-erase load pulses from firmware, converter VSEL toggling
   (2.6/3.0/3.3 V) and re-init, AUX toggling, backup-domain reset. DBGMCU->CR
   is confirmed 0x0 after POR.

4. Why a "debugger reset" seemed to heal it: the heal is a statistical side
   effect, not the reset. Boot current transients of the full application
   (CPU2 start, sensor measurement bursts) can randomly kick the converter out
   of its bad operating point. With a minimal quiet binary (no CPU2, no
   sensors), 0 of 8 debugger resets healed - including real NRST pulses. My
   original "deterministic: debugger reset always heals / POR never" table was
   an artifact of always testing heals with the full firmware.

Cross-check against public sources

We did an extensive literature/web sweep before posting this. Result: this
exact failure state is not publicly documented anywhere - no datasheet note,
no errata, no forum thread we could find. So treat this post as a first
report. What the public sources DO support:

1. ST1PS02 datasheet (DS13206, st.com/resource/en/datasheet/st1ps02.pdf):
   documents no faulty power-up state at all (startup is described only as a
   fixed few-ms soft-start with 280 mA switch limit). But its 100% duty-cycle
   mode thresholds match our clean/bad boundary exactly: the mode is entered
   with VIN falling below VOUTnom + 200 mV (typ) and left with VIN rising
   above VOUTnom + 300 mV (typ); in 100% mode the regulator is OFF and VOUT
   is connected to VIN through the high-side MOSFET. With a 3.3 V target that
   puts the leave threshold at ~3.6 V typ - and our measurements show clean
   POR at 3.3 V, unstable at 3.45 V, stable bad mode from 3.6 V. Both
   thresholds are typ-only (no min/max), and the cold power-up behavior
   inside the VOUT+0.2...0.3 V band at uA load is not specified - our failure
   window sits exactly in that unspecified region. Also: the measured 6-19 mA
   is four orders of magnitude above the specified 500 nA quiescent current.

2. ST's own STEVAL-ASTRA1B (UM2966, AN6044) is the interesting counter-
   example: it uses the very same ST1PS02CQTR (twice), permanently fed from a
   LiPo (3.7-4 V, i.e. always VIN > VOUT 3.3 V), and ST characterizes it at
   9.4-12 uA in low-power mode - no bad mode mentioned anywhere in the
   58-page AN6044. The decisive schematic difference: on the ASTRA1B the
   ST1PS02's EN is NOT tied to VIN. A D-flip-flop startup circuit (~150 nA
   shelf mode) keeps the converter disabled after battery insertion; only a
   button press or USB presence raises EN - i.e. the converter is only ever
   enabled AFTER VIN is stable (and it starts at VOUT = 2.5 V, firmware
   raises it to 3.3 V later). Functionally that is exactly the "delayed
   enable" mitigation. (ST motivates it as a shelf-mode feature, so this is
   circumstantial, not proof.)

3. Generic light-load converter literature (TI SLVA866A on minimum-on-time /
   pulse-skipping during startup, TI SLVAFD6 on adaptive-COT converters
   reaching undocumented harmful states outside normal operation, ADI Analog
   Dialogue on PWM-at-uA-load efficiency collapse and PFM/PWM mode-transition
   hazards) supports the mechanism class, though none describes a persistent
   latched high-loss state like this one.

So all the M4-side evidence in my original post was correct (both cores in
deep sleep, all registers bit-identical, only BORRSTF differing) - it was
correctly telling me the MCU sleeps fine and the current is drawn elsewhere on
the board. I mis-attributed it to the CPU2 RF analog domain; the actual
consumer sits in front of the MCU, in the power stage.

Takeaways for others

- If your STM32WB board "does not enter Stop2 after power-on but sleeps after
  a debugger reset", measure the current with the MCU halted at the first
  instruction, and vary the supply voltage at power-on. If the behavior
  depends on VIN vs the regulator's VOUT target, it is your power stage, not
  the WB.
- STEVAL-PROTEUS1 specifically: powering the board at or below 3.3 V (the
  ST1PS02 VOUT default) avoids the state entirely; a fresh LiSOCl2 cell
  (~3.6-3.67 V) and the kit's own Li-Po (3.4-4.2 V) both land in the bad
  range. Whether the STBC02's soft SYS-rail ramp-up (battery + S2 wake-up
  path) changes the picture is still open on our side; the hard power-on at
  those voltages reliably does not.
- For ST: it may be worth characterizing the ST1PS02 power-up behavior at
  light load with VIN slightly above VOUT (3.3 V target, 3.45-3.6 V input,
  uA-range load) - i.e. cold power-up into the region just above the
  100%-duty leave threshold (VOUTnom + 300 mV typ), which the datasheet
  leaves unspecified. Two board-level suspects on the PROTEUS worth a look:
  EN tied directly to VIN (no delayed enable - unlike ST's own ASTRA1B, which
  gates EN through a startup flip-flop and shows no such issue at VIN > VOUT),
  and the D0-D2 select pins bootstrapped to the converter's own output, so
  the VOUT target moves 2.6 V -> 3.3 V during the ramp. I can provide the
  full measurement series.

Thanks to everyone who read the original wall of registers. Case closed on
the STM32WB side.
 

1 reply

P
PeterAuthorBest answer
Associate
July 2, 2026

SOLVED - and the STM32WB is innocent. Root cause is the ST1PS02 step-down
converter on the STEVAL-PROTEUS1 board, not the MCU, not CPU2, not the wireless
stack. I am correcting my own post so nobody chases the wrong lead.

What actually happens

The ST1PS02 (400 mA nano-quiescent buck, hysteretic control) can latch into a
high-loss operating state when it POWERS UP with VIN above its VOUT target
(3.3 V static default on this board: the D0-D2 voltage-select pins have 1 M
pull-ups - note they are bootstrapped to the converter's OWN output
ST1PS02_VOUT, so during the ramp the pins read low first and the target moves
2.6 V -> 3.3 V while the converter starts; EN is tied directly to VIN, so the
converter starts right on the battery-insertion edge). In that state the board
draws a broadband ~6-19 mA
(median ~10 mA) at the supply, regardless of what the MCU does. When it powers
up with VIN at or below the VOUT target, the state never occurs.

The decisive experiments

1. Supply-voltage A/B/A test (same firmware, same board, PPK2 source mode,
   power-on reset each time):
     POR at 3.0 V  ->  ~35 uA sleep   (OK)
     POR at 3.3 V  ->  ~39 uA sleep   (OK)
     POR at 3.45 V ->  ~9 mA, unstable
     POR at 3.6 V  ->  ~10.5 mA, stable  (the reported "bug")
     POR at 3.8 V  ->  ~10.4 mA, stable
     POR at 4.2 V  ->  ~10.1 mA, stable
   Fully reproducible in both directions. Note the 3.8/4.2 V points: the
   ENTIRE Li-Po range is affected, i.e. this also hits the standard
   STEVAL-PROTEUS1 kit configuration with the supplied 480 mAh Li-Po
   (consistent with a side observation: our kit battery drained from full to
   empty in ~37 h ~= 13 mA average while the MCU-side telemetry looked
   perfectly healthy).

2. Boot bisection: an eternal Stop2 loop as the VERY FIRST instruction in
   main() - before HAL_Init, clocks, GPIO, BSP, and with CPU2 never booted
   (C2BOOT never set, no BLE at all) - still shows ~14 mA after POR vs ~4 mA
   after a debugger reset. The excess current exists before the firmware
   executes anything and without the RF subsystem ever running. This
   definitively rules out CPU2 / RF-analog / wireless-stack causes.

3. No MCU-side action clears the state (each tested individually): NRST pin
   reset (CubeProgrammer -hardRst), software reset, RCC_APB3RSTR.RFRST pulse,
   hci_reset, flash-erase load pulses from firmware, converter VSEL toggling
   (2.6/3.0/3.3 V) and re-init, AUX toggling, backup-domain reset. DBGMCU->CR
   is confirmed 0x0 after POR.

4. Why a "debugger reset" seemed to heal it: the heal is a statistical side
   effect, not the reset. Boot current transients of the full application
   (CPU2 start, sensor measurement bursts) can randomly kick the converter out
   of its bad operating point. With a minimal quiet binary (no CPU2, no
   sensors), 0 of 8 debugger resets healed - including real NRST pulses. My
   original "deterministic: debugger reset always heals / POR never" table was
   an artifact of always testing heals with the full firmware.

Cross-check against public sources

We did an extensive literature/web sweep before posting this. Result: this
exact failure state is not publicly documented anywhere - no datasheet note,
no errata, no forum thread we could find. So treat this post as a first
report. What the public sources DO support:

1. ST1PS02 datasheet (DS13206, st.com/resource/en/datasheet/st1ps02.pdf):
   documents no faulty power-up state at all (startup is described only as a
   fixed few-ms soft-start with 280 mA switch limit). But its 100% duty-cycle
   mode thresholds match our clean/bad boundary exactly: the mode is entered
   with VIN falling below VOUTnom + 200 mV (typ) and left with VIN rising
   above VOUTnom + 300 mV (typ); in 100% mode the regulator is OFF and VOUT
   is connected to VIN through the high-side MOSFET. With a 3.3 V target that
   puts the leave threshold at ~3.6 V typ - and our measurements show clean
   POR at 3.3 V, unstable at 3.45 V, stable bad mode from 3.6 V. Both
   thresholds are typ-only (no min/max), and the cold power-up behavior
   inside the VOUT+0.2...0.3 V band at uA load is not specified - our failure
   window sits exactly in that unspecified region. Also: the measured 6-19 mA
   is four orders of magnitude above the specified 500 nA quiescent current.

2. ST's own STEVAL-ASTRA1B (UM2966, AN6044) is the interesting counter-
   example: it uses the very same ST1PS02CQTR (twice), permanently fed from a
   LiPo (3.7-4 V, i.e. always VIN > VOUT 3.3 V), and ST characterizes it at
   9.4-12 uA in low-power mode - no bad mode mentioned anywhere in the
   58-page AN6044. The decisive schematic difference: on the ASTRA1B the
   ST1PS02's EN is NOT tied to VIN. A D-flip-flop startup circuit (~150 nA
   shelf mode) keeps the converter disabled after battery insertion; only a
   button press or USB presence raises EN - i.e. the converter is only ever
   enabled AFTER VIN is stable (and it starts at VOUT = 2.5 V, firmware
   raises it to 3.3 V later). Functionally that is exactly the "delayed
   enable" mitigation. (ST motivates it as a shelf-mode feature, so this is
   circumstantial, not proof.)

3. Generic light-load converter literature (TI SLVA866A on minimum-on-time /
   pulse-skipping during startup, TI SLVAFD6 on adaptive-COT converters
   reaching undocumented harmful states outside normal operation, ADI Analog
   Dialogue on PWM-at-uA-load efficiency collapse and PFM/PWM mode-transition
   hazards) supports the mechanism class, though none describes a persistent
   latched high-loss state like this one.

So all the M4-side evidence in my original post was correct (both cores in
deep sleep, all registers bit-identical, only BORRSTF differing) - it was
correctly telling me the MCU sleeps fine and the current is drawn elsewhere on
the board. I mis-attributed it to the CPU2 RF analog domain; the actual
consumer sits in front of the MCU, in the power stage.

Takeaways for others

- If your STM32WB board "does not enter Stop2 after power-on but sleeps after
  a debugger reset", measure the current with the MCU halted at the first
  instruction, and vary the supply voltage at power-on. If the behavior
  depends on VIN vs the regulator's VOUT target, it is your power stage, not
  the WB.
- STEVAL-PROTEUS1 specifically: powering the board at or below 3.3 V (the
  ST1PS02 VOUT default) avoids the state entirely; a fresh LiSOCl2 cell
  (~3.6-3.67 V) and the kit's own Li-Po (3.4-4.2 V) both land in the bad
  range. Whether the STBC02's soft SYS-rail ramp-up (battery + S2 wake-up
  path) changes the picture is still open on our side; the hard power-on at
  those voltages reliably does not.
- For ST: it may be worth characterizing the ST1PS02 power-up behavior at
  light load with VIN slightly above VOUT (3.3 V target, 3.45-3.6 V input,
  uA-range load) - i.e. cold power-up into the region just above the
  100%-duty leave threshold (VOUTnom + 300 mV typ), which the datasheet
  leaves unspecified. Two board-level suspects on the PROTEUS worth a look:
  EN tied directly to VIN (no delayed enable - unlike ST's own ASTRA1B, which
  gates EN through a startup flip-flop and shows no such issue at VIN > VOUT),
  and the D0-D2 select pins bootstrapped to the converter's own output, so
  the VOUT target moves 2.6 V -> 3.3 V during the ramp. I can provide the
  full measurement series.

Thanks to everyone who read the original wall of registers. Case closed on
the STM32WB side.
 

Terms & ConditionsAccessibility statement