STM32H563 SRAM ECC Byte Writes: Explain the Hidden Read Before the Write

A byte store to ECC-protected STM32H563 SRAM can detect an error while firmware appears to be only writing. The SRAM interface first reads the containing 32-bit word, merges the changed byte or halfword, and writes the word back. That hidden read participates in ECC checking.

The scope is an address in H563 SRAM2 with its ECC option enabled, following RM0481 Rev 5, section 6.3.2, pages 255–256. No option byte was changed, no memory corruption was injected, and no target exception was observed. The objective is to attribute a reported fault to the correct access and protection unit.

Expand the byte address to its ECC word

The SRAM ECC code covers 32 data bits with seven check bits, providing single-bit correction and double-bit detection on reads. A subword write therefore needs the old surrounding bytes before it can construct a replacement word and its ECC.

Let B be an aligned address in the selected SRAM2 region. A write at B + 1 updates one byte but causes the interface to read the word spanning B through B + 3. The diagnostic boundary is that word, not only the byte selected by the instruction.

For a healthy-word, little-endian merge example:

address:          B      B+1    B+2    B+3
old byte:         0x44   0x33   0x22   0x11
write at B+1:            0xAA
merged byte:      0x44   0xAA   0x22   0x11

The resulting data word would be 0x1122AA44 if the prior word is valid and the operation completes normally. This arithmetic does not describe the outcome after an uncorrectable read. If that hidden read detects a double error, do not assume the intended store repaired the containing word or preserved trustworthy neighboring bytes.

A halfword store has the same documented whole-word read-modify-write mechanism. Inspect the actual access width in the compiled code and the final linked address. A source-level assignment name or structure member type alone is insufficient to locate the transaction that reached the SRAM interface.

Establish that the region is protected

SRAM2 ECC depends on its configured enablement. H563 SRAM1 does not have the same ECC feature, and SRAM3 has a split layout: when its ECC is enabled, the first 256 KB is protected, the next 64 KB is unprotected, and the final block stores ECC rather than application data.

Consequently, “the pointer is in SRAM” is too broad a premise. Identify bank, address range and effective configuration before applying the hidden-read explanation. Do not disable ECC or change option bytes as a quick diagnostic fix; that changes the protection and possibly the startup assumptions being investigated.

This article does not presume uninitialized cold-start RAM is the cause. Reset erase, explicit initialization and previous memory damage are different histories that need independent evidence. The mechanism explains how an existing ECC condition can become visible during a subword store, not how that condition originated.

Qualify the captured address and status

The H563 RAMCFG double-error status is DED. The associated address update requires double-error interrupt or NMI enablement through DEIE or ECCNMI, and address latching through ALE is also part of the documented capture conditions.

A value left in RAMCFG_MxDEAR cannot be assumed to identify the latest operation without those conditions and the status history. The manual also warns that further double errors cannot be detected while DED remains set. Preserve the diagnostic evidence before following the supported acknowledgement and recovery procedure; clearing status is not a repair of corrupted memory.

Map the captured location according to the selected bank’s address-register definition, then compare the containing ECC word with the actual store address. Do not treat the byte lane as the full scope of the integrity check.

Keep buffering separate from the fault explanation

The documented byte/halfword access latency is two AHB cycles. The merge occurs in a buffer whose contents reach SRAM two AHB cycles after the SRAM AHB interface is released. This is an additional reason not to equate an instruction’s apparent completion with an invented universal persistence guarantee.

It does not supply a cache-maintenance or barrier recipe, and this article proposes none. A diagnostic review should distinguish an explicit load, the hidden read inside a subword store, and a separate reset or initialization event. The useful result is a supported fault attribution with the correct bank, access width, ECC word and valid status context, rather than a blanket claim that a write cannot report a read-side integrity error.