STM32H563 SRAM2 After Backup Reset: Place Initialization After the Actual Erase
A record placed in STM32H563 SRAM2 can disappear during backup-domain initialization even when the linker keeps it out of ordinary zero-initialized data. ES0565 documents a hardware erase triggered by a particular backup reset. Moving the record into a no-initialization section does not prevent that erase.
The problem is startup ordering: the data must not become live until the relevant erase has finished. This article uses ES0565 Rev 8 and RM0481 Rev 5 for H562/H563/H573. It does not claim that SRAM2 survives complete power loss or every low-power transition.
Identify the memory before discussing retention
H563 SRAM2 is a 64 KB region. The device also has a separate 4 KB backup SRAM associated with the backup supply domain. They are different physical memories. A record being called a “backup record” in application code does not place it in backup SRAM.
Use the final linker address to determine where the record, stack and early runtime objects actually reside. The H563 datasheet describes the SRAM organization and VBAT-backed resources. The relevant RM0481 RAMCFG descriptions describe SRAM erase and reset configuration.
This distinction matters because the erratum names SRAM2, not merely the explicitly backed-up memory. Its consequence can reach objects that a developer would not associate with RTC initialization.
Locate the actual destructive transition
ES0565 section 2.2.14 specifies the condition: when VSWRST in RCC_BDCR and DBP in PWR_DBPCR are both set, the backup-domain reset also erases SRAM2. The applicability table marks revisions A, Z, X and W as affected.
Do not broaden this into “every RTC access erases RAM.” The documented trigger is the stated backup-domain reset condition. Search the actual startup and RTC configuration paths for that operation, including board initialization and recovery branches. A helper named “initialize RTC” may perform a destructive domain reset under only some conditions.
Conversely, do not narrow the effect to the RTC registers because that was the caller's intention. The erratum defines an additional SRAM2 consequence. A startup sequence that initializes a live SRAM2 object and then performs this reset can invalidate the object even though the C runtime has already completed.
Put normal SRAM2 use after the erase boundary
ST's workaround gives a concrete order. After exiting reset, check in SystemInit that no SRAM erase is ongoing. Reset the backup domain, wait until SRAM2 erase is complete, then proceed with normal application execution and store data in SRAM2.
That sequence deliberately accepts the SRAM2 erase. It is not a method for preserving preexisting contents through the backup reset. If a requirement demands those bytes survive that operation, this workaround does not satisfy the requirement; the storage or reset policy needs a different supported design.
Review everything that can touch SRAM2 before the final wait completes. An early stack, constructor, boot-stage handoff object or interrupt routine can make the memory live sooner than the application considers itself started. The correct boundary is the first actual dependency on those bytes, not a convenient function named “application init.”
The final ELF and startup sources should agree on this boundary. A linker exclusion can prevent ordinary zeroing, but only the hardware sequence controls the documented erase. Treat the two mechanisms separately when diagnosing a lost record.
Keep option-byte erase behavior separate
Section 2.2.6 documents another SRAM erase hazard: clearing SRAMx_RST can immediately trigger an SRAMx erase. The note limits this occurrence to once after system reset, and only if the option was set to one during that reset. The prescribed workaround is to reset the application immediately after clearing it.
This is a different trigger from the backup-domain reset. Do not combine them into a vague claim that SRAM2 is unreliable. Identify whether the observed path changes SRAMx_RST, asserts the backup reset, or does neither. Then apply the applicable sequence and limitations.
Option-byte changes belong in a controlled provisioning or configuration procedure. An application should not casually change the retention/reset option on a running system whose stack or data occupies the affected SRAM. The erratum explicitly warns of exceptions or unpredictable behavior when erased memory is in use.
Test the ordering, not a hoped-for byte pattern
On an approved development fixture, instrument the startup milestones around the erase status, backup reset, erase completion and first SRAM2 write. Keep the observation mechanism outside the region being erased. Otherwise the trace buffer can disappear with the object it is meant to diagnose.
A useful positive test initializes a nonsecret SRAM2 record only after the documented completion boundary and verifies it during normal execution. A separate controlled case establishes that the startup path actually performs the intended backup reset. Do not infer a supported preservation guarantee from a single run in which bytes happened to remain visible.
No startup test or board measurement was performed here. The deliverable is an ordering constraint tied to a specific documented erase: complete the required backup-domain operation and its SRAM2 erase before any ordinary owner relies on SRAM2 contents. That addresses the hardware cause instead of repeatedly changing linker attributes around it.
