[STM32F7] BKPSRAM lost after hard reset

[SGheo.1]

Hello,

 

I’m working of a TM32F769 board the content of the 4 KB backup SRAM (BKPSRAM,
0x40024000) is lost after a hard power cycle (VDD removed and re-applied),
although:

  - VBAT is supplied by a 3 V lithium coin cell (Renata, CR1225-type),
  - the backup regulator is enabled (PWR_CSR1.BRE = 1) and ready
    (PWR_CSR1.BRR = 1) before power-off, and BRE is still set at the next
    cold boot,
  - the rest of the backup domain is retained: RCC_BDCR keeps its value
    (LSE on/ready, RTCSEL = LSE, RTCEN = 1) and the RTC keeps running,
  - HAL_PWREx_EnableBkUpReg() returns HAL_OK,
  - BKPSRAM content IS retained across system resets (NRST / IWDG) while
    VDD stays present.

 

The test I have performed:

 1. Flash and run the firmware once (writes 0xDEADBEEF to BKPSRAM word 0).
 2. Disconnect the ST-LINK cable from the board (to avoid back-powering
    through SWD pins).
 3. Remove all board power (VDD). The coin cell stays connected to VBAT.
 4. Wait for 5 min.
 5. Power the board up without the debugger and let it boot.
 6. Connect the ST-LINK and attach without reset (Reset behaviour = None,
    no download, core resumed) and read the globals via Live Expressions
    without halting the core.
 

Result: BKPSRAM has garbage value.

Could you please provide any hints on what might be the issue?

 

[waclawek.jan]

I don’t know the reason for failure, but how is VDDA connected?

JW

[KDJEM.1]

Hello ​@SGheo.1 ;

 

First of all I recommend you to check the configuration mentioned in RM0410 Rev 5 to retain backup SRAM.

To retain the content of the RTC backup registers, backup SRAM, and supply the RTC when VDD is turned off, VBAT pin can be connected to an optional standby voltage supplied by a battery or by another source.

To allow the RTC to operate even when the main digital supply (VDD) is turned off, the VBAT pin powers the following blocks:

• The RTC

• The LSE oscillator

• The backup SRAM when the low-power backup regulator is enabled

• PC13 to PC15 I/Os, plus PI8 I/O (when available)

The switch to the VBAT supply is controlled by the power-down reset embedded in the Reset block

 

Thank you.

Kaouthar

[SGheo.1]

Thank you. However, in my case the power is not fully lost: only VDD is removed, VBAT (3 V coin cell) stays connected.
This is proven by the backup domain itself: after 5 min without VDD, RCC_BDCR = 0x8103 is retained (LSE running, RTC enabled), so the device was in VBAT mode, and the RTC and LSE were powered from VBAT as described in RM0410 chapther 4.1.5.
According to the same section, the backup SRAM should also be powered from VBAT when the backup regulator is enabled. BRE = 1 and BRR = 1 before power-off, and BRE is still 1 at the next cold boot, yet all 4 KB of BKPSRAM are lost. PDR_ON is tied to VDD.
Why would the backup SRAM lose its supply in VBAT mode while the RTC and LSE on the same VBAT domain keep theirs?

[MM..1]

Live expression is buggy sometimes, stop code and read memory in expression or memory window

[Pavel A.]

Are any tamper pins enabled? Glitch on a tamper pin can trigger erase of backup RAM.

 

[db16122]

Please check the comments from the datasheet as below:

The Data TCM RAM is accessible by the GP-DMAs and peripherals DMAs through specific AHB slave of the CPU.The instruction TCM RAM is reserved only for CPU. It is accessed at CPU clock speed with 0 wait states. • 4 Kbytes of backup SRAM This area is accessible only from the CPU. Its content is protected against possible unwanted write accesses, and is retained in Standby or VBAT mode.

The backup SRAM only retain the data value at standby and VBAT mode. If the power is fully lost, the data will be lost

[waclawek.jan]

the BKPSRAM in ‘F7 is *not* TCM

[db16122]

Please check the feedback below is helpful or not:

## Summary

On STM32F769, **BKPSRAM retention through VDD removal is expected only when the device really enters VBAT operation and the dedicated backup regulator remains enabled**; in that case, VBAT supplies the RTC, backup registers, and backup SRAM, and `PWR_CSR1.BRE=1` with `BRR=1` is the documented condition for BKPSRAM retention in VBAT mode.  
From the official documentation, the **strongest hardware hint to check first** is **`PDR_ON`**: if `PDR_ON` is connected to VSS, **VBAT functionality is no longer available**, so backup SRAM retention after VDD removal is not possible in that configuration.

## Detailed Explanation

### 1) What the documentation says must be true for BKPSRAM retention

When VDD is not present, **VBAT operation is activated**, and the **VBAT pin supplies the RTC, backup registers, and backup SRAM** on STM32F769.  

For STM32F76x/77x, the **backup SRAM is powered by a dedicated low-power regulator** when the backup domain is supplied from VBAT, and its retention in Standby/VBAT mode depends on the **`BRE` bit in `PWR_CSR1`**:  
- `BRE=1` → backup regulator ON → BKPSRAM retained  
- `BRE=0` → backup regulator OFF → BKPSRAM lost in Standby/VBAT mode.  

The **`BRR` bit** indicates that this backup regulator is ready.  

Also, the reference manual states that **`DBP` must be set before writing `PWR_CSR1.BRE`**, and that **`BKPSRAMEN` must be enabled** for backup SRAM access.

### 2) What your observations suggest

Your report that **RTC keeps running** and **`RCC_BDCR` retains its configuration** means the **backup domain itself is being retained** across the VDD-off interval.  

However, the official STM32F76x/77x documentation says that **if VBAT is present and the backup regulator is enabled, BKPSRAM should retain its content** in VBAT mode.  

So, based strictly on the documentation, your symptom is **not consistent with the normal intended VBAT retention path**. The most likely documented conclusion is that **BKPSRAM is not actually being powered in VBAT mode during the VDD-off interval**, even though the RTC portion of the backup domain is retained.

### 3) The first hardware item to verify: `PDR_ON`

The datasheet gives one very specific condition that disables VBAT operation: **if `PDR_ON` is connected to VSS (internal reset OFF), VBAT functionality is no longer available, and the VBAT pin should be connected to VDD**.  

If your custom board uses that configuration, then **retention of BKPSRAM after removing VDD is not possible**, regardless of `BRE` software handling.

### 4) Why this does *not* look like a backup-domain reset

The reference manual states that a **backup-domain reset** resets **RTC registers**, **`RCC_BDCR`**, and **`BRE`** to their reset values, but **BKPSRAM is not affected by that reset**.  

So if `RCC_BDCR` is preserved in your test, that argues **against** a backup-domain reset being the explanation.  

The manual also says that **BKPSRAM is not mass-erased by a tamper event**.  

And it further states that **the only way to erase BKPSRAM is through the Flash interface when changing read protection from level 1 to level 0**.  

So the documentation does **not** support “normal backup reset” or “tamper erase” as the cause of your symptom.

### 5) A useful sanity check from the datasheet: expected VBAT current

For STM32F769, the datasheet gives **VBAT-mode current with backup SRAM ON, RTC ON, and LSE ON** as about **2.4 to 2.6 µA typical**, depending on LSE drive, with **3.4 to 3.7 µA maximum**.  

That means the official expectation for retention mode is a **very small but measurable VBAT current**. If you can measure the VBAT path during the VDD-off interval, this is a useful check of whether the chip is actually in the documented “backup SRAM retained from VBAT” state.

### 6) Practical conclusion from the documentation

From the official STM32 documents alone, the most relevant hints are:

1. **Verify `PDR_ON` is not tied to VSS**, because that explicitly disables VBAT functionality.  
2. **Confirm the device is truly entering VBAT operation when VDD is removed**, because that is when VBAT is supposed to supply BKPSRAM.  
3. **Confirm `BRE` was enabled with `DBP` access allowed and `BRR=1` before power removal**, because that is the documented retention requirement for backup SRAM in VBAT mode.  
4. **Do not focus on backup-domain reset or tamper as the primary cause**, because the official documentation says those do not match the symptom pattern you described.

**Could you check and confirm how `PDR_ON` is wired on your custom board, and whether you can measure the VBAT current during the VDD-off interval?**

[waclawek.jan]

> Glitch on a tamper pin can trigger erase of backup RAM.

Nice try, but this is in the high-end ‘L4 (and possibly some newer), not in ‘F7.

JW

[Pavel A.]

​@waclawek.jan You’re likely right, the F769 documentation does not mention that tamper resets BKPSRAM  - only the  RTC backup registers, and if enabled so in the RTC config. 

To exclude the tamper version, the OP can also check if the RTC backup registers are lost together with the BKPSRAM : will the value after “loss” be 0 or anything random ? The latter will mean a “normal” Vbat power glitch.

 

 

[waclawek.jan]

> Why would the backup SRAM lose its supply in VBAT mode while the RTC and LSE on the same VBAT domain keep theirs?

I don’t know, but are you sure the BKPSRAM content is corrupted? How exactly do you test that? After the power cycle, do you check that you have BKPSRAM clock enabled in RCC, DBP set in PWR_CRx?

How is VDDA connected?

JW

 

[SGheo.1]

Thank you for your reply. Here are the answers to your questions.

1. Is the BKPSRAM content really corrupted, and how do we test it?
Yes. We don't check a single word. We check the whole 4 KB with a known pattern:

Before power-off, all 1024 words are written (word 0 = 0xDEADBEEF, the rest = 0xA5A5A5A5), and the readback is correct.
After the cold boot (RCC_CSR = 0x0E000000, POR + BOR + PIN), all 1024 words are compared at the start of main(), before any code writes to BKPSRAM.
Result: 1024/1024 words wrong, 19475 of 32768 bits flipped (9624 0→1, 9851 1→0). Word 0 = 0x3368C7E8, a value that is nearly identical in every run and looks like an SRAM power-up pattern.
With the same code and the same check, BKPSRAM content is retained across NRST and IWDG resets while VDD is present.

2. Are the BKPSRAM clock and DBP enabled when the check is done?
Yes. Before the check we enable the PWR clock, set DBP and enable the BKPSRAM clock. The registers captured immediately before the first BKPSRAM read are:

RCC_AHB1ENR = 0x00140000, so BKPSRAMEN (bit 18) = 1
PWR_CR1 = 0x0000C100, so DBP (bit 8) = 1

Additional result from the same power cycle: we also wrote 0xDEADBEEF to RTC_BKP31R. After the power cycle:

RTC_BKP31R = 0xDEADBEEF (retained)
RTC_BKP0R (our startup counter) = 21 (retained)
RCC_BDCR = 0x00008103 (LSE on, RTC on LSE, retained)
PWR_CSR1 at boot = 0x00000209 (BRE = 1, BRR = 1)

This shows that VBAT supplied the backup domain for the whole power-off period and that no backup domain reset or tamper erase occurred. Only BKPSRAM, which depends on the backup regulator, lost its content.

[waclawek.jan]

That sounds the BKPSRAM content is genuinely the power-up one.

One outstanding possibility is, that those values were never actually been written to BKPSRAM in the first run; I assume you’ve already double-checked that, too, by reading them back. I also assume you don’t do anything unexpected like setting MPU to allow caching of the BKPSRAM area.

Can you please tell, how is VDDA connected? I’m asking because in the ‘F4/’F7 it appears to be related to the VBAT switchover. I do acknowledge that the RTC/backup-register is retained, but the SRAM and its LDO is a somewhat higher power consumption and maybe there is some timing sensitive component to the switchover. Also, are *all* VDD/VSS (VSSA) pins connected, I mean, including checking for bad solder joints. What package is this? Isn’t there a PDR_ON pin, and if yes, is that connected properly?

Also, can you please try to recreate the issue on a “known good board” like Nucleo or Disco?

JW

 

[Lucian Romonti]

Things I would check:

• Backup regulator on (BRE = 1) and stabilized.
• After BRE on, no other part of the code does not alter the configuration.
• Id D-cache active? If so define an MPU region with MPU_ACCESS_NOT_CACHEABLE (start at BKPSRAM_BASE and size of your backup SRAM).

Had the same issue and the problem was d-cache.

[waclawek.jan]

> Had the same issue and the problem was d-cache.

Let me guess: in ‘H7.

The difference is, that while in ‘H7 the BKPSRAM is in the 0x2000’0000-0x3FFF’FFFF area (which is by default Normal/Cacheable), in ‘F7 it’s together with peripherals in the 0x4000’0000-0x5000’0000 area, which by default is Device/Non-cacheable; and it would take a deliberate action from the user to set up cache for it, in which case he would be aware of that. Probably.

JW