Powering cycling STM32F4 board corrupts flash programming

[timkutscha9]

Posted on August 14, 2012 at 19:43

Hi All,

  Has anyone had problems with corrupting their flash programming when power cycling their STM32F4xx board? (or any other STM32 board for that matter)

I'm able to use the boot-loader to successfully flash code to an STM32F407 board and use it through several resets.  Occasionally when I turn off power to the board, it fails to boot back up, arguably due to corrupted flash programming.

Is there any special voltage power-down sequences I need to follow to prevent affecting the internal flash memory at power-down? 

Are there any pins I could control the voltage on to prevent flash programming from being affected during an unexpected power-down event?

I'm not writing any flash sectors during operation, so as long as I can use the boot-loader to reflash the system, I'm happy to lock down all flash sectors in any way possible.

Thanks for your time and suggestions!

Cheers,

Tim

#flash

[frankmeyer9]

Posted on August 14, 2012 at 19:55

Occasionally when I turn off power to the board, it fails to boot back up, arguably due to corrupted flash programming.

 

If so, it should misbehave through further power cycles, until reflashing. I suggest to read out the Flash in this case, and compare it to the original.

If the failure disappears after power cycling, this points to a latent bug, or some hardware issue.

I never had such a problem with several different discovery boards of differnt type (VL, F0, F4). It has always been bugs...

[frankmeyer9]

Posted on August 14, 2012 at 19:55

Occasionally when I turn off power to the board, it fails to boot back up, arguably due to corrupted flash programming.

 

If so, it should misbehave through further power cycles, until reflashing. I suggest to read out the Flash in this case, and compare it to the original.

If the failure disappears after power cycling, this points to a latent bug, or some hardware issue.

I never had such a problem with several different discovery boards of differnt type (VL, F0, F4). It has always been bugs...

[Tesla DeLorean]

Posted on August 14, 2012 at 20:28

As suggested, read out the content of the flash, should be pretty obvious if it's corrupted or not. Then you'd know.

Check that you have the BOOTx pins set suitably for normal operation.

The devices should boot using the HSI clock, if you are using the PLL or HSE, you should probably check if these things are working, and stable. A lot of ST's demo code will spin in endless while loops if subsystems aren't working properly.

Use your JTAG/SWD debugger and trace through the startup of the device.

[timkutscha9]

Posted on August 15, 2012 at 01:06

Thanks for the input.  I'll read out the contents after the boot failure to see if things are actually getting corrupted.  In the meantime, I'm also trying to set the BOR (brown-out reset) level to 2.7-3.6 volts up from its base level and setting the write-protect bits in the flash user option register.

The system seems to work fine again after I reflash it with the boot-loader, so I'm still thinking it's memory corruption, but it could be the firmware hanging on PLLs locking or something else.

I'll keep everyone posted on what I find.

Thanks again for all the help!

Cheers,

Tim

[frankmeyer9]

Posted on August 15, 2012 at 17:03

It would really surprise me if the Flash is corruptible that easy.

I assume that the booster stages to generate the erase/program voltages are only fired up when you unlock the Flash properly.

And without that rather high voltages, the Flash is physically read-only.

[timkutscha9]

Posted on August 15, 2012 at 20:20

Hi fm,

I did some experiments yesterday and confirmed that the flash programming was indeed getting corrupted.  Here are the steps I went through:

• I flashed driver 11 with the JTAG probe
• After ten power cycles, the unit failed to boot
• I dumped the flash contents to a file
• I flashed driver 11 over the serial port AND set the write-protect bits and raised the reset/brownout(BOR) level to a higher voltage
• I dumped the flash contents to a file and verified that the contents dumped above had bytes corrupted to zero in flash sector 0
• I power cycled the unit over thirty times without failures
• I dumped the flash contents a third time and verified there was no corruption of flash

In short, setting the write-protect option bytes and also raising the BOR (brown-out-reset) level to 3 with the user option byte solved the problem.  The system is running at 3.3V, so setting the reset level higher seems to be a no-brainer.

The corrupted bytes were all in page 0 of the flash and the bytes were corrupted to zeros.  When erased, the contents are all FFs, so something was driving those flash bits to zero.

While I find this unnerving, our team found similar issues on power-down with external SDcard flash parts used with other micro-controllers.  I hope others find setting these option bytes useful.

Cheers,

Tim

[OVeli.1]

Hi, I have faced with the same issue and I can add that WP is not working, only BOR to the highest level solved the problem with the corrupted Sector 0 of Flash for STM32F407 MCU. Please find the detailed report here: https://community.st.com/t5/stm32-mcus-products/corrupted-flash-in-vector-table-area-sector-0/m-p/684115/highlight/true#M251736

[Tesla DeLorean]

Posted on August 15, 2012 at 21:23

Do you have any code in your firmware that erase/writes to FLASH/EEPROM?

Do you have any checksum/crc integrity checking in your firmware?

[frankmeyer9]

Posted on August 16, 2012 at 09:15

As said, that surprises me ...

The corrupted bytes were all in page 0 of the flash and the bytes were corrupted to zeros.  When erased, the contents are all FFs, so something was driving those flash bits to zero.

 

That is correct, '1' is the erased state of a Flash bit cell, associated with 'no charge on floating gate'. To get the bits to zero, there needs to be an active write.

If you can prove that you have no IAP code that is activated under that circumstances, I would contact ST. I have heard rumours about other Flash related issues, but not yet about such a corruption.

While I find this unnerving, our team found similar issues on power-down with external SDcard flash parts used with other micro-controllers.

 

My first assumption would be a process related problem.

If those SD cards utilizes Flash produced with the same technology, they would surely share some problems.