Accessing "Backup SRAM" with RDB Level 1 from Code in RAM

[Microman]

Hi all,

I am not sure if I understood the reference manual right: When I activate Read Out Protection RDP Level 1, I can no longer access RTC Backup registers if I execute in RAM. I did not read that also Backup RAM is inaccessible. But it looks it is the case...

My problem is that I use the 128k version of the STM32H7 and I must run the firmware in RAM. But I also need a low power retenion memory. Leaving D3 on to keep SRAM4, uses too much power (few mA). HAL_PWR_EnterSTANDBYMode() from hal_pwr.c works fine for me - except that it clears SRAM4.I tried other STOP modes but the source too much. BTW there is no tamper alarm activated (at least not by me).

Is there a way accessing Backup SRAM from code running in AXI/SRAM1,2,3 etc?

[Muhammed Güler]

You can use RDP and backup registers at the same time. RDP is there to limit what it can do with the debugger.

I suggest you review the following document

https://www.st.com/resource/en/application_note/an4701-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf

[waclawek.jan]

> I am not sure if I understood the reference manual right: When I activate Read Out Protection RDP Level 1, I can no longer access RTC Backup registers if I execute in RAM

Where do you see that in RM?

My copy of RM0433 rev.7 in Readout protection (RDP) subchapter of FLASH chapter says, that

• both Backup SRAM and RTC backup registers have the same behaviour in this regard, cumulatively called "other secured regions"
• when RDP Level 1, access to "other secured regions" is allowed unless "intrusion" happened
• "intrusion" means boot from RAM or system memory (built-in bootloader), or debugger attached
• as far as these rules go, there's no restriction from where code executes

I'd say that "debugger attached or debugger was attached" implies at least a power-on reset after debugger has been removed.

JW

[Microman]

I walked through a lot of documents today and one application note from ST (not in the RM) told that accessing the Backup Regs from code executed in RAM is for security reason (possible code injection) not possible if RDP is on level 1 or 2. I'm really sorry, I was trying to find that document again but was unable so far. Maybe it was from another STM32 family, not sure.

My problem comes from my boot strategy I guess:

Initial Program Load after power on is from Flash. The loader loads the RAM Firmware from external flash into AXI RAM. Then, it changes the Boot Config to RAM and reboots -> "intrusion" means boot from RAM.

 HAL_SYSCFG_CM7BootAddConfig(SYSCFG_BOOT_ADDR0, (u32)APPLICATION_RAM_ADDR);

 NVIC_SystemReset();

So, my problem would be solved if I don't reset the controller after RAM loading but manage to start the RAM code directly with no reboot. I'll try that next.

EDIT: It is reproducible that the system works as desined if RDP = 0. Backup SRAM stays consistent, keeps its values.

When RDP is programmed to 1 in advance, Backup SRAM is always cleared to zero.

All tested without any debug probe connected.

[Microman]

Hi, thanks for the document. Yes there is my issue: I reconfigure boot address and boot into RAM. I would need to find a way to start the RAM application without reset. I tried that already but alltough I De-Inited all the hardware (with HAL_DeInit()) USB for example does not work properly at the RAM application... We will see but now it is clear what the issue is.

[waclawek.jan]

Please, let us know about the results.

Meantime, please note that BKPSRAM (confusingly called BKPRAM in 'H7 RM, ST really likes to shoot its customers into their leg) is located in a memory area which is by default tagged Normal (so you may need to put barriers around BKPSRAM accesses although I still believe the barrier in that particular thread simply provided the needed delay), and Cacheable (so you may need to evict cache after BKPSRAM write), and has ECC, so your BKPSRAM writes may need to be 32-bit aligned word writes.

JW