Cannot read fresh Stm32H723 flash after first program + reset

[arena_chris1seto]

I have an STM32h723, connected to the STM32CubeProgrammer via SWD. My flash image is 136672B in size and contains code to read the entire flash image, SHA3 it, and then compare that SHA3 to an SHA3 which is located, via linked script + post build scripts, at the end of flash. This code is known to work fine across many Stm32 targets, including this one when the flash image is smaller than 0x0001fec0 bytes. 

However, on this stm32H723, that code generates a hardfault (bus fault,  BFAR[M] = 0x0801fec0), but *only after the first bootup*. The first bootup it works fine. During investigation, I tried simply writing the image file with stm32cubeprog and then reading it back. If I verify it back right after programming it works fine. If I power cycle the board, then try to verify against the same file, I get the following error: "12:46:41 : Error: Data mismatch found at address 0x0801FEC0 (byte = 0x54 instead of 0x74)"

So both my program code and access to the Stm32 via SWD are showing that flash at this address cannot be read after a single boot cycle. This is a fresh Stm32 out of the tray, and the PCROP start = 0xff, end = 0x00, DMEP = unchecked. ROP is AA. It's my understanding that both of these features would then be disabled?

Any ideas on what is going on here?

Thanks!

[Tesla DeLorean]

Is it a binary file or a hex file?

Is it possible that it has voids in it, ie gaps not multiples of 64-bits (8-bytes) the FLASH/ECC line width?

[STOne-32]

Dear @arena_chris1seto ,

Is this fresh part out of tray - the only one having this behavior and how many tried parts in total . To know if deterministic on all parts ? If yes, hypothesis’s of @Tesla DeLorean  is right one to either confirm or eliminate.

Ciao

STOne-32

[arena_chris1seto · Accepted solution]

Turns out this has a dumb solution. I forgot that my code contained a routine which wrote to flash at a hard coded address. The previous version of the project had that area of flash reserved for this purpose, this new project did not, and with the image being 130KB, it busted into that flash region. Ooops. My mistake. My guess is that the bus fault was due to ECC getting sad when the flash was clobbered, but that's just a guess.  

I confirmed that when I use a 130KB image of all ascii a's, I could write/verify across reboots. Doh. Thanks guys

[STOne-32]

Dear @arena_chris1seto 

Good to know that you figured out the issue 🙂

Have a great day and Welcome again in our community.

Ciao

STOne-32