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

[LCE]

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

That sounds so much like what Tesla said, power on reset problem.
So could you somehow fiddle an external 3.0V reset controller into that design?

And what's the problem with USB power detection? That should not be too hard.

Anyway, even without the reset controller this should not happen.

[Nikita91]

 

Some time ago I had a problem like this with an Atmel ATmega. A few months apart the flash was corrupted.

The problem came from an RS422 driver which was powered before the MCU, and therefore the MCU was poorly powered by a GPIO. Once the RS422 power supply has been modified: no more problems.

Maybe look over there?

[seiko_eng02]

Hi ypiotrp

Do you get this problem solved?

We got the similar issue like yours.

If it is possible could you share the  solution?

 

Regards, Kou

[Tesla DeLorean]

With an H7B0 on a custom board?

Schematic? 

[seiko_eng02]

Not STM32H7B0.

Our device is based on STM32L412KC.

But We got the similar problem that the  the first sector of internal flash is erased.

Our device is power by battery only。

It has been confirmed that a reset occurs due to a drop in battery voltage due to instantaneous current.

[ypiotrp]

Hi @seiko_eng02 ,

Try to set Write Protection in option bytes of the MCU. In our case it helped.

Regards,
Piotr

[seiko_eng02]

Hi ypiotrp

Thank you for your response.

I think you have set both BOR and Write protection in the previous description.

＞We configured BOR to 2.7V which is the highest possible value. We also enabled the Write Protection Option. I haven't seen any

＞option to configure POR. 

Is it correct to think that BOR settings are actually unnecessary?

In our case, we believe if we set the BOR to a high voltage threshold, more resets will occur.

if there is no need for the BOR setting, it will not be set.

Regards,
Kou

[Pavel A.]

Still this sounds strange. If the WRP helped you @ypiotrp this hints to the "regression" path (if  code execution path which does a normal erase, with software unlock, can be excluded).  Otherwise, STM32H7 has brown-out protection, specially to prevent running with invalid voltage. Should it suffice, or external anti-brown out circuit is required?