STM32H7B0 internal flash gets erased during runtime

[ypiotrp]

Hi,

We develop a device based on STM32H7B0. We use this microcontroller with QSPI external flash. In the internal flash we keep our bootloader and in the external flash resides application code. We are now testing our devices and we had 3 cases when the internal flash got erased. In result the devices act "dead" becuase there is no code to initialize and start the application from the external flash.

Why does it happen? Nowhere in the bootloader nor in the application code we use instructions to unlock the internal flash, not speaking of instructions to erase it. Is there any other option for the internal flash to get erased?

Regards, Piotr

[FBL]

Hello @ypiotrp,

Could you specify how do you program the Flash memory? and How does it get erased? Is it a full mass erase including system flash memory? Would you please make sure that no more than 256 Mbytes are addressed? 

Thanks

[Tesla DeLorean]

Any EEPROM emulation being used?

Generally I wouldn't expect devices to spontaneously self-erase. Perhaps issues with power, or VCAP? Data not writing properly initially? ECC failure on the flash lines? Some security mechanism triggered?

Code in ROM capable of doing an erase.

[FBL]

Hello again @ypiotrp,

Would you please share your software inbox or contact a local FAE?

[Pavel A.]

 Power supply noise can cause erasure of internal flash on STM32H7? Or can it trigger RDP up & regression? How wonderful...

[Tesla DeLorean]

Generally it is the result of unpredictable code execution, and then issues if the operation can't source enough charge to erase or write.. Or a process that's started and fails to complete as the supply collapses. Say shutdown initiated EEPROM write / update.

Other platforms that use lock/unlock keys for FLASH tend to avoid MCU side code in possession of the keys, and have them supplied externally via PC side tools. This however can be impractical in some cases, like IAP / FOTA, and ST has all the code/keys as part of it's stock Flash library code. Code fragments which are also part of the System ROM.

Generally the best protection is to have external POR circuits clamping the devices in reset, that hold reset for 100's of milliseconds, and have thresholds close to normal operational voltages, rather than have a device that's marginally functional down in the 1.1 / 1.2 V ranges. POR that covers both power up and down scenarios.

[ypiotrp]

Hi @FBL,

We have an External Loader prepared for our QSPI external flash memory and we use it to program. It has 8MB of capacity. I woul like to clear out that only the internal flash memory gets erased (128 KB inside the STM32H7 uC). The external flash stays untouched

[ypiotrp]

We do not use EEPROM emulation in our project. 

I wouldn't either expect memory to spontaneously self-erase. Today I went through the reference manual looking for answers and found nothing. Indeed there are some security mechanisims (Temper detection) but they should cause such a behaviour. They only erase some part of memory (called security or something like that) resposinble for e.g. keeping some security keys. 

The programming process was done without raising any red flags so the data was written properly. 

Nowhere in our bootloader nor in application code we use flash unlock instructions, RDP or internal flash programming. We program the external QSPI flash during the FOTA process but it is not the case here

[ypiotrp]

@Tesla DeLorean @FBL 

You say that some problems with power supply could cause unexpected self-erase of internal flash memory? Do I understand you correctly? 

Our device is powered with 5V form USB but also has a small LiPo battery. We have some problems with detecting the event of unpluging the USB cable. This leeds to several restarts because the voltage of the battery drops. After that the voltage is too low for the device to boot up. Could it be the root problem and the flash erase is only a symptom of that?

It sounds quite impossible to me. Until today I considered flash memory untouchable because of the lock mechanism and special keys that have to be inserted into specific registers before the flash program or erase operation would be possible. 

[ypiotrp]

Hi,

Today we had another case of that issue. The device was left for some time without external USB power. Probably it experienced several restarts due to low battery voltage. We read the memory with CubeProgrammer and found out that only the first sector of the internal flash got erased (first 8KB of flash). 

Is that symptom tell us something more about the root cause of this issue?

Regards, Piotr