In newer STM32 (such as the 'L4 family and newer), amongst the low-power modes, the Shutdown mode is the lowest-power mode available with VDD still connected. Compared to Standby, in this mode, every clock (including LSI and thus IWDG) and every VDD-derived circuitry are powered down. This results in sub-uA supply currents in the VDD domain. Only VBAT-domain circuitry (including RTC and backup registers, if enabled) remains active. Similarly to Standby, the only way to wake-up from Shutdown is reset (or reset-inducing action from RTC/TAMPER).
However, switching off all VDD-related circuitry means also switching off the brown-out detector. According to documentation, this has the following consequence:
The BOR is not available in Shutdown mode. No power voltage monitoring is possible in this mode, therefore the switch to Backup domain is not supported.
In Shutdown mode, the following features can be selected by programming individual control bits:• real-time clock (RTC): this is configured by the RTCEN bit in the Backup domain control register (RCC_BDCR). Caution: in case of VDD power-down the RTC content will be lost.
To confirm this behaviour experimentally, a simple experiment was conducted. On a 'L476-DISCO, the 0R resistor R90 connecting VDD to VBAT has been removed, and to the decoupling capacitor at VBAT C79 a parallel 100uF ceramic capacitor was added, which, when charged, provides several minutes of RTC run time in VBAT mode. This capacitor was charged simply by shorting the pads of missing R90 manually by tweezers 1.
The test program was derived from a simple "clock" application, which runs the RTC and displays the time at the on-board LCD. To this, an addition was written - when joystick-down is pressed, the mcu goes into the Shutdown mode. To confirm, that it's Shutdown rather than Standby mode, after reset, three items are displayed: content of PWR_SR1 (to display the SBF flag indicating Standby) and content of a SRAM1 and a SRAM2 word written previously by a "magic" number 2. This feature was needed, because it was found that the same program run while debugger is attached, enters Standby mode rather than Shutdown (this may be undocumented behaviour of the mcu, but also artefact of the used debugger(?), did not investigate further).
So, the expectation was, that:
- normal operation: while the "clock" is running, after removing VDD (by disconnecting the USB connector, or the Idd jumper) for a couple of seconds and then restoring it, RTC displays the correct time as if no VDD interruption happened - this worked as expected
- confirming Standby: after pressing joystick down, LCD ceases to display time (and current measured at the Idd pins with removed jumper) drops dramatically (did not have a multimeter with proper sub-uA capability to confirm exact current, measured some 0.6uA which is roughly consistent with DS values); again, after several seconds reset by button restores operation, with LCD displaying expected values for Shutdown (see above) and then correct time - this worked as expected
- shutdown-then-VDD-removal: after placing mcu into Shutdown by pressing joystick down, VDD was removed and shorted by tweezers at the pin headers (3V-to-GND); and then after several seconds restored - expectation was, based on the quote from RM above, that RTC is either reset, or corrupted, or at least stopped incrementing during the time while VDD was removed.
However, the observation was, that no matter whether the mcu was placed into Shutdown or not, the RTC kept running correctly after VDD removal/restoration.
The explanation provided by ST for this effect is, that in Shutdown, the backup-domain power switch may, but also may not, switch to VBAT properly to maintain RTC during the VDD power down. In other words, there's no guarantee that RTC will keep running when VDD powers down, but there's also no guarantee that it won't. The system has to be designed to take this behaviour into account, and if RTC has to be maintained during VDD powerdown, Shutdown can't be used.