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.

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

[LCE]

> could this be caused by ESD issues ?

That's always a possibility, and it is not always destructive.

But the way I'm handling the "naked" boards on my desk here (custom PCBs, Nucleos - kinda first EMI test by developer sloppiness ... :D), either PCB layout must be really bad or / and you have some strong EMI sources nearby.

Have you tried putting the PCB into a case?

  

[Ratschaka]

An airport radar or eye level, about 200m distance from where the boards are tested might count as strong EMI source, not sure though.... :D

I would not expect the flash to corrupt or anything else with ESD, at least the flash...

 

[Ozone]

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

A few weeks ago I had a somewhat similiar problem with a Raspberry Pi Zero.
It booted up fine, and I could login via ssh.
However, a few minutes after running apt update / apt upgrade, the connection was lost and the board unresponsive.
Not only that, the SD card was irretrievably corrupted.

As it turned out, the power supply was only marginally sufficient.
It was ok under lght loads, but under higher stress, the supply fell below the brown-out level, and the system crashed.

I would highly recommend to investigate and check the power supply rails, perhaps compare yours with reference designs. I'm not a hardware developer, I would add.

> An airport radar or eye level, about 200m distance from where the boards are tested might count as strong EMI source, ...

Not sure what you mean with "eye level".
But an airport radar is unlikely the cause, this is usually directed radiation, pointing upwards.
If your location is hit by the direct beam from 200m, you will have much more serious problems than just crashing STM32F407 boards ...