STM32H7 Internal Flash Error

cameronf · ‎2019-03-21

I'm having trouble reading/writing to internal flash on an STM32H743XI. For a while I've been erasing/programming sectors of internal flash from a custom bootloader without issue but I somehow got the chip into a state now where 4 sectors can no longer be read from and instead trigger a hardfault. I think it has to do with ECC but I'm having trouble verifying that or clearing the error. The issue persists through power cycle. The HAL functions for erasing/programming flash still execute on these bad sectors and return HAL_OK but if I try to read data anywhere in these sectors the MCU hardfaults.

Anyone have an idea of what the issue is and how to resolve it?

Debugger is also unable to access this memory as shown below:

Andreas Bolsch · ‎2019-03-22

If there's an ECC error, this would probably affect only several 8-byte blocks, not entire sectors (if they were not overwritten without previous erasure). Did you check this?

I guess PCROP was engaged accidentally for these sectors, that would cause the very symptoms you described.

andre239955_st · ‎2019-03-22

If you have a debugger/programmer like Segger JLink you could completely erase the chip including option bytes.

cameronf · ‎2019-03-22

Full chip erase (didn't have to reset option bytes) resolved the issue for now, though I still haven't figured out the cause.

cameronf · ‎2019-03-22

Fixed it for now with a full chip erase, but still haven't found what triggered it. Do you know if PCROP protected sections result in bus faults when a debugger is attached? Based on the reference manual it seems like PCROP sections should return 0x00 for data fetches.

Dat Tran · ‎2019-11-26

I am having same issue, erasing will get the flash work back but that is not a fix. Any one has progress on this, please?

alister · ‎2019-11-26

From RM0433 section 3.3.10

If you rush to recover by erasing (with protection removal) you'll not learn the cause.

At least connect using e.g. STM32CubeProgrammer and check the option bytes first.

andre239955_st · ‎2019-11-26

We also use a home made bootloader and use it for all ST families, including H7. Last week we had a similar problem, it was due to not waiting long enough for the programming cycle to complete. We NEVER use HAL functions, only LL to have better control of what should happen.

We had a big problem on a STM32G070 where we wanted to activate the read protect. The option bytes did not program correctly because we didn't wait long enough. We are unable to erase the chip after that. Not even with JLink or CubeProgrammer. DFU mode doesn't work either. The reference manual is not always complete...

Dat Tran · ‎2019-11-27

Hi,

How did you know it didn't wait enough? where did you add the delay, please?

I am using ST driver which is already implemented check busy bit before enter / exit write / erase. I also added some delay after write / delay manually. It doesn't help. Most of the time work fine, about 10% reproduce when test.

Thanks for the help!

andre239955_st · ‎2019-11-27

Hi,

For normal flash programming (not option bytes) the micro will stall if you try to access the flash while programming or erasing. Adding a loop will have no effect. But you need to be carfull if you have the watchdog activated to avoid a reset during programming! You should do a refresh just before and make sure you can finish the programming in time.

For the option bytes it is a bit more tricky. We had put a reset just after the programming the option bytes. For this programming the micro did not stall and executed the reset before the programming was finished. We saw that the programming failed.

Hope this helps.