STM32F429 Automatically Enables Write Protection

[abdullahcavuss]

Hello guys,

In some of the products we developed with STM32F429, we received the write-protected error I mentioned in the image. I know how to turn off write protection, but I can't figure out how it activates independently. However, there are also malfunctions in other parts of the products on which I receive this error.

Footnotes:

• ROP Level 0, BOR Level OFF in option bytes
• There is a powerful capacitor in the input power; it takes about 50ms to discharge (I'm not sure if it's helpful information.)

 

 

[waclawek.jan]

> BOR Level OFF

Why?

Switch it on, and check, if the problems with write protection remains.

JW

[abdullahcavuss]

I have done many tests, including brownout tests, but I could not catch the same error. My aim is to find out why it is happening, I do not think it is related to BOR.

[TDK]

Look at option bytes in STM32CubeProgrammer. Does it agree with the statement that write protection is on? What values in there are responsible? Do other option byte values look corrupted as well? Does your program modify option bytes at all?

[abdullahcavuss]

I'm using ST-Link Utility. The pic shows the option bytes when write protection is activated. Yes, it agrees with the statement that write protection is on.
My program doesn't modify the option bytes and internal flash.

I did some power cuts while applying option bytes. Then all option bytes changed, not only write protection. In my issue, only nWRP changes(all sectors).

 

[TDK]

After a quick search, I don't think anyone has reported this before. If write protect option byte is written last, theoretically it could be in a reset state if power is interrupted at the right time, but if you're not modifying option bytes or flash at all, that's not a realistic scenario.

I'm out of ideas. Please post if you figure it out.

[Bob S]

> However, there are also malfunctions in other parts of the products on which I receive this error

What kind of malfunctions and in which "other" parts?  Other parts of the board?  Other parts of the firmware?

You have no code that writes to FLASH?  Not even somehow linked into the final binary but not called (that SHOULDN'T happen as the linker should strip out unused functions).

Only think I can think of is supply voltage transients, but I'm not sure that would cause this kind of failure (writing OPT bytes to zeros).  But as @TDK first commented, I would enable BOR because you don't want the CPU executing (or mis-executing) code when the voltage rail is out of spec - no telling WHAT it would do.  Specially with a large cap and slow discharge time where it could spend significant time in the nether region of "enough voltage to run but not enough to be guaranteed to run correctly".  If for some reason you can't use BOR, then an external voltage monitor/reset generator (probably too late for an already built board).

[Tesla DeLorean]

At power-up have your firmware dump the internal states of the Option Bytes to get a view from the inside, without needing a debugger or programmer.

Parts that have come back for some other reason, ie the flash got erased, product looks non-functional or crashes early in the normal boot up process?

I'd generally avoid doing reconfiguring or modifying flash immediately after boot up.