Best practice for reading EDATA

[Biohazard]

7.3.4 FLASH read operations
4. If the application reads … high-cycle data not previously written, a double ECC error is reported …

When storing a variable amount of data to high-cycle flash, or dealing with setting up a new/blank MCU, the SW needs to check high-cycle flash which may be empty.

I am looking for a good best-practice for how the flash is meant to be used. One option I am looking at disabled the ECC NMI (ironically) and checks if non-0xffs are present before clearing faults and re-enabling the NMI and reading the data.

This only really works if it can be assumed the data is complete. It will still results in faults if data is not complete for some reason.

Another option I can think of is handling the ECC NMIs and just allow normal reads, catch and clear ECC errors and report failure.

Is there any solid recommendation on what to do? I can’t find any application note with examples.

[mfgkw]

You talk about a STM32F7?

[mfgkw]

---

 

[Biohazard]

That is the STM32H575xx to be more specific.

[Hai]

Hello ​@Biohazard 

Thank you for your pertinent question.

For STM32H5 high-cycle data Flash area, the recommended best practice is not to rely on raw reads of potentially uninitialized content to determine whether data is valid.

When a location has never been programmed, or when a write is incomplete, the ECC logic may report a double ECC error, so the read path alone is not a reliable validity mechanism.

The recommended approach is to design the data format as self-validating, for example with:

• a magic/marker word
• a version field
• a length field
• a CRC or checksum

With this scheme, the software can read and validate the structure safely, and only then use the data. If the data is blank, incomplete, or corrupted, it should simply be considered invalid and reinitialized.

In general, I would not recommend disabling the ECC NMI as a normal operating mode to probe the content of EDATA. That approach can mask issues and does not provide a robust solution for partially programmed content.

A better practice is to keep ECC handling enabled and treat an ECC fault as a signal that the block must be rejected and reinitialized.

 

Best regards,

Haifa.