STM32 gotchas
133. PA2 unexpectedly outputs a 32kHz signal? RTC behaves strangely? Maybe consequence of VBAT brownout.

In STM32G071 errata (ES0418), the following erratum appeared, dated 17-Oct-2022:

Corrupted content of the RTC domain due to a missed power-on reset after this domain supply voltage drop

The RTC domain reset may be missed upon a power-on following a power-off, if its supply voltage drops during the power-off phase hitting a window, which is few mV wide before it starts to rise again. In this critical window, the flip-flops are no longer able to safely retain the information and the RTC domain reset has not yet been triggered. This window is located in the range between 100 mV and 700 mV, with the exact position depending mainly on the device and on the temperature.
This missed reset results in unpredictable values of the RTC domain registers. This may cause a spurious behavior (such as driving the LSCO output pin on PA2 or influencing RTC functions).

It is not clear, which STM32 are affected, but based on anecdotal observation of "mysterious failures" which match this description, reported on the forum, it at least affects also some of the STM32L4. A similar report by user arnold_w indicates, that 'F446 is likely be affected, too - and in this case, it affected PA0. ST does not always propagate such finding to all affected models' errata timely, so it may quite well be that all STM32 are affected.

What might be the worst-scenario consequences of this issue?

It appears, that if the VBAT brownout (i.e. VBAT voltage decreasing to the critical window and then rising again) occurs, the backup-domain1 registers' content may end up in any random state. These registers are mainly registers of RTC (and TAMP in families where it's a separately described unit), but also the backup-domain control register, RCC_BDCR1. It may well be that in certain STM32 a few spurious bits scattered across peripherals also belong to backup-domain, always check your STM32 RM.

In applications, which do use the backup-domain facilities (RTC, backup registers, LSE to clock asynchronous peripherals such as LPTIM or LPUART) the consequences of spurious change of these registers/bits is obvious. However, there are also consequences to applications which don't use the backup-domain facilities, or use only some functionalities of them while the spurious change sets other functionalities.

One such consequence may be unexpectedly higher power consumption, e.g. due to inadvertently enabled LSE; other may be unexpected interrupt or register clear through tamper input. But maybe the most dangerous consequence is, that some backup-domain registers bits enable to override the GPIO settings of certain pins, changing their intended functionality or even causing hardware conflict by unexpectedly turning them to output. Some of such pins are PC13 (the common RTC-output-tamper-etc. pin), PC14/PC15 (OSC32 pins for LSE), PA2 (LSCO pin), and they may be more - the Additional functions column of Pin definitions table in DS to given STM32 model may be helpful in identifying such pins.

There are three groups of applications, regarding VBAT connection/usage:

  1. Backup domain (mainly RTC) is not used at all, VBAT connected to VDD either through internal bond in the low-pin-count devices, or externally as per datasheet guidance.
    The recommended workaround is to explicitly reset backup domain ( using RCC_BDCR.BDRST). This is probably the most common usage model, and perhaps the most dangerous for this particular issue, as users who don't use actively backup-domain (RTC) features are not likely to associate any problem with backup domain/RTC, nor to actively seek issues related to the backup domain/RTC. Thus, the problem violates the unwritten "if you don't use it, simply don't touch it, the default state is OK" rule.
    I expect ST will be adding such reset quietly to all CubeMX-generated code which did not have backup-domain facilities clicked, but users who don't program by clicking in CubeMX ought to be warned, too. Given above analysis the erratum is not appropriate enough for this, ST should consider adding conspicuous warnings directly to RM (probably to the Reset subchapter of RCC chapter).
  2. Backup domain (mainly RTC) is used only while VDD is present, VBAT connected to VDD in the same way as above.
    The recommended workaround is again explicit backup-domain reset in the startup code, however with one exception: if Standby mode is utilized, the user may want to avoid the backup-domain reset. The erratum in ES0418 contains a long, winding and relatively complex description of the possible workaround (i.e. discrimination of power-on reset from reset-to-exit-standby).
  3. Backup domain is actively used with battery (or capacitor/supercap) connected to VBAT.
    This case is not mentioned in the erratum, but this may be one of the most problematic cases, especially if the battery is not maintained actively or if a capacitor (often supercap) is used in place of battery on VBAT. In case of battery, using only batteries from reputable sources with well-known characteristics, regular measurement of VBAT voltage through the facility built into ADC, and/or counting usage time and estimating future lifetime may be part of the solution. In any other case, comprehensive registers checksumming, estimates based based on on- and off-time timing, and similar techniques can/should be employed.

1. The STM32L0 family does not have a separate VBAT pin, nonetheless it does have a supply-domain which behaves in the same way as the backup-domain in other STM32 families - here it's called RTC domain. Into this belong the RTC registers, and selected bits in RCC_CSR ('L0 does not have a separate RCC_BDCR register). It's not clear, if 'L0 is affected by the same brownout problem, but pending further information from ST it's reasonable to err at the safe side and assume that it is.