flash/ECC issue on an STM32H743.

[Pieter Egg]

I'm investigating a suspected flash corruption/ECC issue on an STM32H743.

A read from flash address 0x081F0000 consistently causes a fault. The problem is that I'm not fully confident that the fault status registers can be trusted after the event, so I'm looking for a diagnostic approach that does not rely entirely on the captured fault information.

Known facts:

• Accessing 0x081F0000 triggers a fault.
• ECC_FA2R does not show a failing address.
• STM32H7 flash ECC is evaluated only when flash is read.
• ECC granularity is 32 bytes (256 bits).

My main question is:

If I suspect flash corruption or an ECC problem, but do not fully trust the contents of CFSR, HFSR, BFAR, SR2, or ECC_FA2R after the fault, what is the recommended way to diagnose the problem?

Would you:

1. Perform a controlled BusFault-protected flash scan in 32-byte steps?
2. Use HAL_FLASHEx_ComputeCRC() over the suspect region?
3. Dump the entire flash bank via SWD/JTAG and verify externally?
4. Use some other method?

Has anyone seen a corrupted flash word on STM32H7 that caused faults without providing useful ECC fault information?

I'm interested in the most reliable way to determine whether the root cause is:

• Double-bit ECC corruption,
• Flash content corruption,
• MPU/PCROP/protection settings,
• Or something else entirely.

[Pavel A.]

Have you tried to erase the sector 15 and test reading before programming? How do you put code or data into this sector: by a programmer tool or by in-app programming? If the latter, is the “parallelism” value good? Writing to the same address several times?

> Perform a controlled BusFault-protected flash scan in 32-byte steps?

Yes

> Use HAL_FLASHEx_ComputeCRC() over the suspect region?

No. IIRC there’s errata against using this method.

 

[AScha.3]

>seen a corrupted flash word on STM32H7

No , not me.

+

Try with CubeProgrammer : writing the flash, then read the ..81F… area. So you know: chip sick - or your way to flash it.

[TDK]

You say you don’t trust the chip but you don’t say what it is telling you. What is the content of the hard fault SCB registers? Chip can generally be trusted. That would be the straightforward debug approach, rather than jumping through hoops to avoid a problem that may not even exist.

If reading 0x081F0000 triggers an ECC fault, then that address was likely written to twice. Only you know what your program does and how that could have been achieved.