In STM32F407, to be able to access (read or write) resources in the so-called Backup Domain (i.e. which are powered from the VBAT power pin, when VDD is off), a as a safety measure, PWR_CR.DBP bit has to be set first.

PWR module is on the APB1 bus, which is the "slow peripheral" bus, clocked at max. 42MHz. This means, that in the usual setup, where AHB is clocked at its maximum 168MHz, APB bus clock has to be prescaled by at least 4.

As a consequence, those Backup Domain resources, which are on the AHB bus - i.e. bits in RCC_BDCR register and the BKPSRAM - may be unaccessible until the write to PWR_CR.DBP actually reached the PWR_CR register. Due to buffering on the AHB/APB bridge, the processor may attempt to access those resources sooner, and this access will fail quietly (read will probably return 0, write will be ignored).

The remedy is relatively easy: it's enough to read back the PWR_CR value after write (the read result can be thrown away, there's no need to check if write was successful: it certainly was).

This issue bears outward similarity to the issue described in "Delay after an RCC peripheral clock enabling" erratum; however, the exact mechanism is somewhat different (the latter involves extra AHB cycles, too). It belongs to the group of issues caused by the SoC nature of the 32-bitters.

The issue is pertinent also to 'F405/'F415/'F417, which are an identical chip to the 'F407. I don't know how is it pertinent to other 'F4 family members, but given the underlying mechanism and overall similarity, I believe it is. It may also be present in other families with similar PWR/Backup Domain structure.

This issue has been discussed on the STM32 Forum back in 2013/2014; ST "discovered" it in 2019 as witnessed by "Possible delay in backup domain protection disabling/enabling after programming the DBP bit" erratum in the 'F4 errata rev.11 dated 05-Dec-2019.