2013-08-27 11:48 AM
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 #flash2013-08-27 12:08 PM
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.2013-08-27 01:23 PM
I just wonder why you would want to overwrite a flash erasing to 00 with ff. This, in effect, makes the flash unusable.
Erik2013-08-27 01:33 PM
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.2013-08-27 01:59 PM
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.2013-08-27 02:45 PM
<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 involved2013-08-27 02:58 PM
2013-08-27 04:06 PM
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 parts2013-08-28 08:50 AM
<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. Erik2013-08-28 10:11 AM
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