Overwriting written flash memory with 0xFFFFFFFF on STM32L

[mlakata]

Posted on August 27, 2013 at 20:48

I need a reliably method of overwriting flash memory on a STM32L device (STM32L152CB). On the other STM32F series, this was easy, as I could write zeros on top of previously written flash memory contents reliably. The STM32L seems to have inverted their flash memory polarity, so it is erased to 0x00000000 instead of 0xFFFFFFFF. No biggie, but I can't seem to reliably overwrite my previously written data with 0xFFFFFFFF.

Here is some code I have used for testing    {     uint32_t pattern = 0x04030201;     FlashErasePage(0x0801E000,FLASH_PASSWORD);     for(int j=0;j<64;j++) {        FlashWriteArray(0x0801E000 + 4*j,(uint8_t*)&pattern,4);        pattern += 0x04040404;     }          for(int j=0;j<64;j++) {&sharpif 1         uint32_t pattern = 0xFFFFFFFF;         FlashWriteArray(0x0801E000 + 4*j,(uint8_t*)&pattern,4);&sharpelse         uint32_t pattern = 0x01010101;         for(int i=0;i<8;i++) {            FlashWriteArray(0x0801E000 + 4*j,(uint8_t*)&pattern,4);            pattern <<=1;         }&sharpendifand here is the result of the memory after ''overwriting'' with FFs:ff ff ff bf ff ff ff ff ff ff ff ff ff ff ff fb f7 ff ff ff fd ff ff ff ff ff ff f7 ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff 7f f7 ff ff ff ff ff ff fb ff ff ff ef ff ff ff ff ff ff ff df fe ff ff ff ff ff ff ff ff ff ff 7f f7 ff ff ff ff ff ff fb ff ff ff ef ff ff ff ff ff ff ff ff ff ff ff bf ff ff ff ff ff ff ff ff ff ff ff fb f7 ff ff ff fd ff ff ff ff ff ff f7 ff ff ff df f7 ff ff ff fd ff ff ff ff ff ff f7 fe ff ff ff ff ff ff bf ff ff ff ff ff ff ff ff fd ff ff ff ff ff ff fb ff ff ff ef ff ff ff ff ff ff ff bf fe ff ff ff ff ff ff ff ff ff ff 7f fb ff ff ff ff ff ff fb ff ff ff ef ff ff ff ff ff ff ff bf fe ff ff ff ff ff ff ff ff ff ff 7f ff ff ff ef f7 ff ff ff fd ff ff ff ff ff ff f7 fe ff ff ff ff ff ff bf ff ff ff ff ff ff ff ff fb ff ff ffA you can see, it is not all ''ff'' but a random mix of single bit failures.I experimented with writing patterns such as a shifting bit pattern, and this seems to work better, but I don't know if this is the right thing to do. As the shifting bit pattern is being written, I can see all sorts of weird behaviour in the flash memory. It does seem to finally end up as all FF in this example, but it seems to be by accident. #stm32l #flash

[Tesla DeLorean]

Posted on August 27, 2013 at 21:08

Probably because the ECC is getting broken by you meddling with the data.

Suggest you allocate a word which you don't write at all, until you want to mark the following data as invalid.

[emalund]

Posted on August 27, 2013 at 22:23

I just wonder why you would want to overwrite a flash erasing to 00 with ff.  This, in effect, makes the flash unusable.

Erik

[Tesla DeLorean]

Posted on August 27, 2013 at 22:33

He presumably wants to scrub content.

The problem here is with the presumption about if the cells are single, or multi level, and how correction might be applied when the ECC bits get garbled. One of the original Intel flash parts wanted you to write all zeros before erasing, presumably so the erase got the cells charged consistently.

[mlakata]

Posted on August 27, 2013 at 22:59

I am porting a file journaling mechanism that worked fine on many different STM32F micros. A file block has a status field that was 0xFFFF if unused, 0xsomething if used and 0x0000 if no longer used (marked for garbage collection). When the flash page was garbage collected, the files marked with 0x0000 were not copied to a new page of flash memory.

I was hoping to keep modifications to our firmware library to a minimum, so I was hoping I could just invert 0000 <-> FFFF, and keep all of the logic the the same.It seems I'll have to break our existing firmware library anyways, because the granularity of the writes is 32 bits (for the STM32L) while on the STM32F[124]xx series, it was 16 bits.

[emalund]

Posted on August 27, 2013 at 23:45

<i>A file block has a status field that was 0xFFFF if unused, 0xsomething if used </i>

what you are missing is 0xfff if ERASED, which, of course equals unused #if STM32L UNUSED = 0x0000 #else UNUSED = 0xffff #endif USED = ^UNUSED not very complicated or involved of course, if you are one of those that sprinkle numeric values all over the place, it is a bit more involved

[mlakata]

Posted on August 27, 2013 at 23:58Hi Erik,    I think you missed my original point. I understand how flash memory works and how boolean logic works.My original point was that this does not work on the STM32L because of a hardware issue.What I am looking for (and willing to give up the search for) is a way to write a particular memory location to USED (using your definition). As you can see from the memory dump I showed, if you write USED to a memory location (what was written once before), you do not always read-back USED.On the STM32F family, this worked reliably and it is mentioned somewhere in the documentation or errata that you can always write 0x0000 to a memory location that was previously written, and it will read back as 0x0000.   On the STM32L family this does not work reliably. You can not write 0xFFFF to a memory location and read back 0xFFFF reliably. This is not the same flash technology as on the STM32F, regardless of the overall bit inversion.I imagine that the ECC bits may have something to do with it, but if they are, there is no documentation on the ECC bits of the Program memory.

[Tesla DeLorean]

Posted on August 28, 2013 at 01:06

It's one of those bullet points mentioned at seminars and never really elucidated upon. I too would be interested in the mechanics of it, I suppose it's 36-bit (32+4) scheme similar to PC Server memory.

ST can we please see some kind of App Note or White Paper explaining this, and RAM equivalents (parity/ecc) used on the various STM32 families. Thanks. Other related parts

http://www.st.com/st-web-ui/static/active/cn/resource/technical/document/application_note/DM00080495.pdf

[emalund]

Posted on August 28, 2013 at 17:50

<i>search for) is a way to write a particular memory location to USED (using your definition).</i>

the issue (note: issue, not 'problem') is that UNUSED (erased) is zero.  If you change UNUSED to ff, there is no way but an erase to set it to USED. Erik

[mlakata]

Posted on August 28, 2013 at 19:11

Erik,

 What I would like to implement is#if  STM32FUNUSED = 0xFFFFUSED = 0xsomethingINVALID = 0x0000#elif STM32L UNUSED = 0x00000000 USED = 0xsomething INVALID = 0xFFFFFFFF#else#error Not supported#endifThis does not work because you can't write 0xFFFFFFFF on an STM32L if the memory is already 0xsomething!  If you try, it comes out 0xFFFFFFBF in some cases. That's my whole point.(of course, you can erase the page and write 0xFFFFFFFF, but then you obliterate everything on the page, and I want to keep parts of it).-Mark