STM32F407 Option Byte 0xFF, bricked chip

[Ratschaka]

Hi fellows,

I have a custom board with STM32F407VGT6. The board was able to be programmed via the JTAG (4 wire JTAG interface; Boot pin is pulled low to ground and reset is connected to the JTAG interface (Nrset pin)) with a segger programmer - multiple times at that and can run for hours, however sometimes it code wipes.

The board works fine for some time, but only upon boot-up (at random, happened twice thus far) we have seemingly a code-wipe as well as a bricked chip with the RDP set to 0xFF and unable to do anything with the chip. This does not happen during continuous running of the chip.

We have this across 2 differently designed boards, which are designed according to the reference manual for power supply and for the tests were supplied with external linear regulator with low noise.  

I have seen some posts here but not conclusive solutions or cause for this issue, is it possible to trigger this externally via hardware faults ?

The chip reports back correctly via the STM32Cube Programmer (V2.18) but unable to download or erase flash as option bytes can't be read and report as 0xFF.

Does anyone have ideas or explanations for this behaviour ?

[mƎALLEm]

Hello @Ratschaka and welcome to the ST community,

Such kind of issues needs from you more details: the schematics + the code you are using to reproduce the issue.

Please read How to write your question to maximize your chances to find a solution

[Ratschaka]

Hi thanks for the reply,

I can not post the full schematic as it is propriety, however the power supply setup is as follows:

Regarding the code, we are not deliberately setting the option bytes at all and checked this - hence the question if this is even possible to be set "accidently" or through corrupted code (during loading of the program from the flash).

I do not see how externally we could trigger a code wipe + setting the option bytes, as it happens at random during boot-up.

Is there any specific code segment that might help diagnose this issue, so I can check if it is possible to share this snippet.

[TDK]

Is VREF+ coming up in time to respect VDDA - VREF+ < 1.2 V? Otherwise things look okay.

VDDA/VREF+ decoupling caps don't match datasheet recommendations but I doubt that's it. No decoupling caps on VDD shown. Guessing those are somewhere. Do VDD/VDDA track each other as power comes up? They better.

[Ratschaka]

VDD has decoupling caps and some for buffering (4x10µF, 10x100nF), the vref is a zener based voltage reference that should come fairly quickly.

What does "Do VDD/VDDA track each other as power comes up? They better." mean exactly ?

Thanks for the suggestions and ideas...

[Ozone]

> What does "Do VDD/VDDA track each other as power comes up? They better." mean exactly ?

Settling to the nominal level at about the same time (in the micro seconds range) after power-up.

[LCE]

That looks good enough too, I'd say. Between VDD / VDDA there's only a ferrite bead with 0.15R and then 20uF for VDDA.

Maybe you can try to raise the internal brown-out level (if possible on a F4)?

I always prefer external reset controllers if space and budget allows.

[TDK]

VDD needs to track VDDA per the datasheet. I suggest looking at these on a scope to see them come up. Adding VREF+ in there would also be smart. See the datasheet.

20 uF bulk capacitance is excessive but shouldn't be a problem. Not sure. Might be something else going on.

[Ratschaka]

I will do the tracking upon bootup with vref as well and post the results here !
Thanks for all the tips though, it has not happened since then, could this be caused by ESD issues ?

[Ozone]

> Thanks for all the tips though, it has not happened since then, could this be caused by ESD issues ?

In theory, but this is a question for ST experts who exactly know the silicon.

An ESD discharge usually destroys the input / output stage of the affected MCU pin(s).
How exactly depends on the internal circuitry and physical configuration.

In many cases, protective diodes are blown, get permanently conducting, and cause high currents.