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

[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

[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.

[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

[FBL]

Hello again @ypiotrp,

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

[ypiotrp]

Hi @FBL,

What do you mean by "share your software inbox"? 

[Pavel A.]

Allow sending you private messages in the forum settings -> Private messenger-> turn on private mesages 

[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]

@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 

[Tesla DeLorean]

If you're seeing this a lot, and can induce it relatively easily, clearly warrants more investigation.

You could eliminate potential causes, say a cascading failure of resetting and unpredictable execution, by having an effective POR with a hard threshold. Say 3.0 or 2.7V below which the MCU is clamped in reset, so no code or operation is possible, at all.

Unfortunately the firewall / chinese-wall (metaphor of barriers) for lock/unlock codes being present of the MCU is violated by the System ROM.

Any way to instrument or log Flash ECC errors? ie devices under long-term observation flag issues via a GPIO which is recorded by external/independent monitoring equipment. Monitor the clamped reset state, and perhaps voltage if that can be done in a relatively non-invasive way.

[Pavel A.]

>found out that only the first sector of the internal flash got erased (first 8KB of flash). 

Are we still talking about STM32H7B0 ? So, the first 8K of the 128K sector turned into FFs? 

 

[ypiotrp]

Exactly. You understood correctly. 

[Pavel A.]

Ok. While waiting for more helpful replies, can you recall anything else? High ambient temperature, EMI, radiation, ultrasound?

Consider the brown-out detector (in the option bytes)

[ypiotrp]

Not really. The only thing that comes to my mind is power supply problems. It sounds to me totally strange, because I considered flash memory to be nonvolatile. I would understand if these power supply drops took place during some flash operations such as programming, erasing but nothing like this happens. We erase and program the internal flash once during production and that's all. There is no place in the firmware where we unlock the internal flash to perform such operations.

[ypiotrp]

Hi @Tesla DeLorean ,

Thank you for your answer.

Unfortunately the issue is hard to reproduce. I already tried plugging and unplugging the device from the power source for a several hours and finally I managed to induct it.

Using an oscilloscope I plotted the MCU supply voltage. At the end of the battery discharge it goes below 2,6V. At the very end the voltage start to oscillate. I guess that during that time the uC starts and stops several times. Sometimes it ends with a erased memory.

As I wrote I managed to reproduce this issue on my desk. Again the first sector of the microcontroller's internal flash was erased (0x08000000 - 0x08002000). The STM32H7 has option byte that sets the start address of the program. I've changed it to 0x08010000 hoping that event when the issue happens again the erased memory won't matter. Unfortunately I was wrong. The erased happened again and now the 0x08010000 sector got erased.

Conclusion - not the first sector of the memory but the first sector of the program gets erased. I guess that during lack of power uC reads the first sector of the memory and then it stops because of the voltage drop. And again and again. Somehow it leads to flash memory corruption.

Unfortunately again we have already produced thousands of PCB and they are waiting for soldering. Because of that any hardware modification is not possible. 

Is there any hope for us? Any way to bypass this issue?

Thank you for your help,
Piotr

[Piranha]

You can do a somewhat dumb test - make an absolutely minimal blinky, run it and try to catch the issue. But erase the whole FLASH and put the blinky as the only code on the MCU - no custom bootloaders or anything else.