STM32H7 Internal Flash Error

[cameronf]

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]

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.

[cameronf]

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.

[andre239955_st]

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

[cameronf]

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

[Dat Tran]

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]

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]

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]

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]

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.

[ADunc.1]

The most likely cause of this issue was an incorrect flashing of one or more 256 bit blocks. Read up about ECC in the reference manual on the flash program operation section. It says you must program a full 256 bit block or risk ECC errors. Or partially programming the same block twice can cause ECC errors. Eg, only writing one byte to a flash block instead of the full 32 bytes.

If this happens you will get a hardfault if the CPU tries to access the broken flash location. The debugger will also not be able to read from that location, there will be a gap of 8 words it just shows as ????????.

You can check for this condition by looking at the SNECCERR and DBECCERR in flash SR. It also gives you the address of the first faulty block in the ECC_FAxR register.

This can be dangerous for in field updating. IF you dont flash one block correctly (eg the last block) then try do a CRC on the flash you just programmed it will hard fault. Even more dangerous when your bootloader does the CRC and gets stuck!

[iTTy]

I had some trouble reading internal FLASH of an stm32H755.
Following your indication I discovered that there was an ECC error.
In my case I fixed by erasing the sector.

But, is there any way to check the flash state before reading it in order to prevent hardfaults?

[Tesla DeLorean]

Not sure, would probably be via the FLASH peripheral rather than a direct access.

You can return from Hard Faults, so could implement something like a structured error handler, with a try/catch type arrangement.

[JOwen.1]

We are also getting the strange 32 byte blocks (randomly) that can't be accessed. We have looked at registers when this happens and does not appear to be any protection getting turned on - the flash registers are the same between boards with readable flash and ones with bad sections.

We also have problems when we try to use the standard HAL flash libraries - they just don't work for large amounts of data. If anyone has code that reliably programs the H7 flash memory, we would love to see it.

[ADunc.1]

We use STM32 HAL flash functions on STM32H753 for in service firmware update. We have done hundreds if not thousands of firmware updates with no corruption now. We use simple flash unlock, erase, program, lock. I cant post the code but it does not have anything special in it. Just calls HAL_FLASH_Program. For firmware download, we erase a large block, big enough to take the entire firmware image, then program the flash and verify checksum. Then at boot up, we search for newly installed firmware images where they are verified, then the application code is erased and replaced with the new firmware image. We flash 700kB firmware images regularly.

However, during early development I did manage to corrupt some blocks which caused ECC errors and repeating hard faults during CRC checking. So, I can see there is a potential issue there.