Forum Update - Announcement about May 10th, 2018 update and your password.

FLiP module EEPROM

I need to know exactly which component is used for the FLiP module's EEPROM. The reason is that I'm working on an app for a customer in which data could be saved to it, and I need to look up the number of write cycles that it can endure. It could mean the difference between a product lifetime of one year or 99 years.

Thanks,
-Phil
“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery

Comments

  • 8 Comments sorted by Date Added Votes
  • ST Micro : M24512-RDW6TP
  • Thanks!

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • There are techniques you can use to greatly extend the lifetime of the EEPROM if you aren't storing 32K of data which all changes every second.

    Let's say you have one long, such as a total or counter, which changes very frequently. Dedicate not just four bytes but a larger chunk of EEPROM to the purpose of saving it. Start by initializing the whole thing to an illegal value/blank such as $FFFFFFFF. As you change the value, instead of writing to the same four bytes, overwrite the next four bytes, then the next four after that, then the next four after that, until you reach the end of your chunk. Now write $FF to the whole thing and start over.

    On recovery, start at the beginning and search for the last value that isn't $FFFFFFFF. There you are, and you've extended your EEPROM's useful life by a factor of chunk_size.
  • These EEPROMs have a page size of 128 bytes. Any write to a page incurs a write cycle for the entire page.
    Sapphire
  • A write cycle only wears the bits that change, though. Have tested the method to destruction on smaller EEPROMs. It works.
  • OK, went back to look at old code and OOPS. The EEPROM does have to erase the page before rewriting it, so there is a small change, which is what I actually implemented ten years ago. You don't leave the old non-$FF values in place; you restore them to $FFFFFFFF but advance to the next four bytes. You still look for the first non-invalid long when recovering. The cells that stay $FF through a write cycle do not wear.
  • YanomaniYanomani Posts: 519
    edited February 3 Vote Up0Vote Down
    Since the currently available datasheet for that device at ST's website presents a part number composition scheme that doesn't exactly matches the one VonSzarvas had posted (M24512-RDW6TP), I'm not sure if it (datasheet) still applyes to the ones mounted at the Flip module.

    At the datasheet, there are two write modes available for that devices (three in fact, if that part number does indicates it also has ECC correction hardware inside it):

    Byte Write - only single bytes are affected by each command (more on this is underway, please keep reading)
    Page Write - an entire page (128 bytes) is affected by each command;

    To fully understand the ECC detection and correction hardware one needs to understand that, at those parts, ECC operates on blocks of four bytes, whose address correspond to byte0, byte1, byte2 and byte3 of any given LONG, within device's addressable range.

    For devices whose part numbers agree with the ones that does have internal ECC hardware, a third write mode does really exists, and it has two ways of operation;

    - the first one, when a byte write is commanded, the whole long to wich it pertains is writen, along with the hardware-generated ECC bits (I've found no mention to the number of bits ECC generates/check ECC does generate enough bits to ensure the flagging and correction of up to ONE bit per writen/readen byte). Since this operation is a "commanded write", its not that difficult to account for it, as a write that has being done, in the seek of quantifying the total amount of write cycles the device experiments, before a failure is likely to occur.

    -the second one is extremely subtle, because it can can only occur during read cycles, when ECC hardware currently "checks" if any bit of the addressed byte presents a value that "flags" an ECC error. In this case, when an ECC error is flagged during read, ECC hardware does correct it, executing a "someway unauditable" write at the whole long (four bytes) to wich the one that was read (and repaired by such a "ghost writer") pertains.

    In short, if you write a byte, four are writen (as per ECC hardware operation). If you read a byte, perhaps, unnoticeably, a write can be taking place too, at the four bytes that pertain to the same word long, thus, if you do a write access to four bytes in sequence (within the same long), four writes are done, at the whole group. If you read four, in sequence, up to four writes "could" be also done, at the (long aligned) group.

    Source:

    st.com/content/ccc/resource/technical/document/datasheet/e0/4c/87/45/e8/bd/4f/11/CD00251873.pdf/files/CD00251873.pdf/jcr:content/translations/en.CD00251873.pdf

    st.com/content/ccc/resource/technical/document/application_note/bd/19/70/43/6b/f2/4d/83/DM00158157.pdf/files/DM00158157.pdf/jcr:content/translations/en.DM00158157.pdf

    Henrique
  • At the rate my app will be writing to this device (once every five minutes and to sequential locations), it should last well over 100 years! So, thankfully, I don't even have to think about load leveling and the like.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
Sign In or Register to comment.