Flash ECC ON STM32G0C1

[AJ2]

I’m currently working on implementing and testing Flash ECC on my controller. According to the datasheet, the device supports ECC, and I can see that it is managed through the FLASH_ECCR register.

However, I’m facing some difficulty verifying whether ECC is functioning correctly. Specifically:

• I am unable to find any ECC-related flags in the FLASH status register.
• I’m not sure how to intentionally generate an ECC error to validate my implementation (e.g., to confirm that error handling via NMI/interrupt is working as expected).

Could anyone please guide me on how to reliably trigger a Flash ECC error for testing purposes on this controller? Any suggestions, references, or example approaches would be really helpful.

[GMA]

Hello @AJ2,

Refer to How to write your question to maximize your chances to find a solution post.

[mƎALLEm]

Hello @AJ2 and welcome to the ST community,

Please read this knowledge base article: Injecting and handling ECC errors in STM32H7 flash memory

It's targeting STM32H7 product but I think the same principle applied to STM32G0 product.

Hope that helps.

[waclawek.jan · Accepted solution]

IMO there are two different kinds of FLASH controllers in the STM32 families with ECC - some do allow rewrites of non-blank FLASH rows (and thus deliberately generate a ECC-faulty row), others don't. IMO 'H7 belongs to the former group, and 'G0 to the latter, so, if I am not mistaken, the method from that article won't work with 'G0.

You can search this forum as this issue came up in the past; or you can also experiment with removing power while performing a FLASH operation (erase or write).

The ECC flags are in dedicated registers (FLASH_ECCR;  and in the dual-bank devices, FLASH_ECCR2), see FLASH chapter in RM.

JW

[awild-aoi]

I think @waclawek.jan is right that the H7 example won't work for G0.

I set up a similar test on G0 and am unable to double-program a flash cell with repeated calls to HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, ...). Once the cell contains any 0-bits, calls to HAL_FLASH_Program return HAL_ERROR and HAL_FLASH_GetError returns 8 which corresponds to FLASH_SR_PROGERR.

So with this version of ECC flash that doesn't even allow programming sequences that would produce invalid ECC, is there a way to force or simulate that type of fault for testing an application's error handling code?

RM0444 section 3.3.6 mentions:

---

Due to the structure of the flash memory (64 bits of data with associated 8 bits of ECC), any ongoing program or erase memory operation interrupted by a physical phenomena such as reset or power-off might result in a corrupted flash memory data and/or ECC bits

---

It sounds like we might need to set up external circuitry to reset or power-cycle the chip at the exact right moment during flash programming.

[waclawek.jan]

> It sounds like we might need to set up external circuitry to reset or power-cycle the chip at the exact right moment during flash programming.

Yes.

Setups like these have been reported here in the past; but I don't have a link at hand, sorry.

JW