STM32F407 RDP issue and flash corruption

[tero]

Posted on November 21, 2014 at 08:06

Hi,

I'm experiencing strange issues with a product based on STM32F407. When doing short power outages to the PCB (uses 24VAC), it sometimes erases or corrupts flash page(s) that are used for eeprom emulation. Pages are 1 and 2 from address 0x08004000. When I try to read flash with ST-link I notice that readout protection has been set to level 1 for some reason, so it's impossible to see what has happened to flash. In my application code I never call FLASH_OB_RDPConfig, so it can't go to level 1 from the application. Also the first line after systemInit() in Main locks the flash memory so I can't figure out what causes the erase.

The power outage has been tested with longer power outages (couple of seconds) automatically multiple thousand times without the problem. Could anyone have a clue what causes this behaviour with short power outages?

#f4xx-readout-flash-rdp

[chen]

Posted on November 21, 2014 at 12:27

Hi

''When doing short power outages to the PCB (uses 24VAC), it sometimes erases or corrupts flash page(s) that are used for eeprom emulation.''

Stating the obvious : Loosing power during Flash write will corrupt the Flash.

Does the design have enough Power before shut down to complete or abandon the Flash write?

''the first line after systemInit() in Main locks the flash memory so I can't figure out what causes the erase.''

I have found through bitter experience that writing to the option bytes during main operation opens a window for the option bytes to be corrupted (eg by the brown out).

In my commercial project - we now only change the OptionBytes during a firmware upgrade. Normal operation, the code does not change the option bytes at all.

Have you enabled brown out protection?

One final point - do not change the Port IO configuration for the debugger port.

(We were doing this early on and it was contributing to the option byte corruption)

[tero]

Posted on November 21, 2014 at 14:52

Hi,

Thanks for your answer! Brownout is set to level 3 already.

I tried removing calling Flash_Lock() from main since its default seems to be locked after reset, and removed the option bytes writing from code and set the brownout from st-link utility instead. Those did not help but we'll try using PWR power control register (PWR_CR) to detect voltage drop below 2,9V and make sure no flash operations are executed after voltage drop interrupt is detected. Unless somebody have experienced similar problem and has a solution...

 

From: sung.chen_chung

Posted: Friday, November 21, 2014 12:28 PM

Subject: STM32F407 RDP issue and flash corruption

Hi

''When doing short power outages to the PCB (uses 24VAC), it sometimeserases or corrupts flash page(s) that are used for eeprom emulation.''

Stating the obvious : Loosing power during Flash write will corrupt the Flash.

Does the design have enough Power before shut down to complete or abandon the Flash write?

''the first line after systemInit() in Main locks the flash memory so I can't figure out what causes the erase.''

I have found through bitter experience that writing to the option bytes during main operation opens a window for the option bytes to be corrupted (eg by the brown out).

In my commercial project - we now only change the OptionBytes during a firmware upgrade. Normal operation, the code does not change the option bytes at all.

Have you enabled brown out protection?

One final point - do not change the Port IO configuration for the debugger port.

(We were doing this early on and it was contributing to the option byte corruption)