Flash corruption and write protection mechanism

[bingojia4ever]

Posted on March 25, 2016 at 09:45

We are using STM32F405 in our product which is a controller. We have met strange problems reported by our customer but can't reproduce the phenomenon in our lab when taking the controller back from customer. The controller works properly after we erase full chip and reload program.

After some analysis, we guess it is caused by flash corruption in data section. We reserve sector 5 to 11 to store some constant data related to some perpherals' setting, if this section got corrupted, the controller won't work properly (it would get stuck somewhere in the program because the perpherals are incorrectly configured).Can anyone give some suggestion on the cause of flash corruption? I have already set the BOR level to highest. I guess it may be because of ESD since our controller don't have any additional protection on ESD.Meanwhile, I am studying write protection of STM32F4 to deal with the flash corruption problem. The related description in datasheet is so vague. I only know that wrtie protection can be enabled by clearing nWRP bits. It only says ''unwanted write operation'' will be prevented but what kind of unwanted wrtie operation could it be? For example, if flash is corrupted by ESD, will write protection helps? Please help to explain the mechanism of write protection and what kind of unwanted write operation could be prevented.Thanks for your help #stm32f4

[Tesla DeLorean]

Posted on March 25, 2016 at 11:24

Did you happen to read the data out before you erased it? What did analysis of that show?

You'd perhaps what to focus on validating the data in your other sectors and have some recovery method before looking at write protection. That would protect you if you unlock the flash and write with the wrong pointer.

[bingojia4ever]

Posted on March 25, 2016 at 15:16

Thanks for your reply clive1.

We didn't read flash content because the chip is read-protected. We have disabled the read protection and send it back to customer. If the problem happen again ,we can check the flash content.While waiting for the problem to re-appear，I am considering the feasibility of enabling write protection. Could you elaborate more on write protection?

[Walid FTITI_O]

Posted on March 25, 2016 at 15:21

Hi bing.fang,

Please, check if you are not at the same conditions which cause the limitation mentionned at the

http://www.st.com/web/en/resource/technical/document/errata_sheet/DM00037591.pdf

 ;  section 2.10.3 page 30. -Hannibal-

[Peter Madsen]

Posted on June 14, 2018 at 12:52

Hi bing.fang,

Did you manage to resolve the issue? We're experiencing the exact same thing, with a data-sector being corrupted when our device is with customers, but we cannot recreate in the lab.

 @FTITI.Walid, section 2.10.3 relates the MAC interface, has nothing to do with internal flash. There is some mentioning of the external NOR/PSRAM interfaces, but I could not find anything on the internal flash.

[Tesla DeLorean]

Posted on June 14, 2018 at 13:59

He might have been referring to an older version of the document, the one posted now is over a year older than the referring post.

Does your code write to flash at all? EEPROM Emulation, etc..

The FLASH has additional parity bits as I recall, also has a self-timing charge pump arrangement, so has dependency on the supplies, bulk-caps and also loss of power during writes.

I've had a handful of devices across my desk that a customer has bricked during updates, don't recall seeing a STM32 device that self immolated the FLASH.

If you're seeing this frequently I'd recommend working with your ST FAE contact to do some QA testing or analysis on the parts to understand the failure mode.

The deactivation of Walid's account suggests he's moved on too.

DAHMEN.IMEN

‌

st.mcu

‌

[Peter Madsen]

Posted on June 14, 2018 at 23:08

Hi Clive,

Yeah, I noticed the old errata reference - check the newest one, same thing.

Yes, our firmware does erase + write flash. Persistent data is loaded from flash boot. Right after, the flash is erased and prepared for data writing. At power-down the persistent data is written back to flash. We start the write process at ~8V supply (before 3V3 LDO) voltage - should be plenty of time to get the data written before the critical 2.7V point (32-bit write width) - and the brown-out is set at 2.9, so I don't see a voltage drop issue.

We're seeing corruption only at the sector that is being written to. And not just at locations that we use, it's all over the sector.

[Pavel A.]

Posted on June 14, 2018 at 23:53

So, do you verify written data immediately after write? This will allow you understand is this a write fault, or the corruption occurs later during normal working mode. If the former, can you consider to repeat erase & write until verification success?

-- pa

[abdullahcavuss]

Hello from the future!

I am experiencing a similar situation. Did you figure out what might be causing the problem? I did several tests but couldn't find it. I did an ESD test, then ST-Link SWD corrupted, and BOR Level and DB1M values changed on the controller.