STM32G070 booting problem after option bytes (user options) modifying/recovering

[dr.look]

Hello,

I am developing a home appliance application on an MCU STM32G070CB using X-CUBE-CLASSB package and IAR EWARM IDE V8.32.4. I used NUCLEO-G070RB for the early development. The app ran fine until I turned on the SRAM parity check in the options bytes.

SRAM parity enabled:

The application jumps to the hart fault handler when calling __iar_data_init3 to initialize RAM variables on startup (similar behavior is described here: https://forum.segger.com/index.php/Thread/5957-SOLVED-MEM-MAP-c-error-with-STM32G071/). However, what is worse for me is that the application is not running anymore when the SRAM parity check is disabled (option bytes recovered).

SRAM parity disabled:

The method STL_StartUp is called from the startup, which performs the startup self-tests including watchdog self-test which performs a reset invoked by each of two watchdogs (two resets overall). However, the MCU is not reset properly and the program instead gets lost somewhere in the system flash memory (0x1FFF 0000 - 0x1FFF 7000) despite setting of nBOOT_SEL = 1 and nBOOT0 = 1 which should ensure booting from the main flash memory (0x08000000) regardless of the BOOT0 pin state.

Now I have two MCUs with the same settings (compared option bytes memory location) and one is working properly and the second one not. The only way to force the MCU to work again is set the BOOT_LOCK = 1.

What is the reason for this? 

[Petr Sladecek · Accepted solution]

Hello,

at principle, SRAM parity error is raised quite reliably when reading sequence of not initialized RAM locations is performed for some reason (by whatever procedure despite no correct code should perform such a reading without previous initialization of this location) after power up when memory content (including the parity information) is fully accidental. Please read suggestion at chapter 3.3 of AN4435. Once you fill the RAM area by whatever content, the parity information becomes initialized, and each next reading from this RAM area should pass correctly (suppose neither HW error is present at the memory logic, nor the location is corrupted later by any attack resulting at swapping of the memory cells content).

Best regards,

Petr