Sunday, November 27, 2011

Avoiding EEPROM corruption problems

EEPROM is invaluable for storing operating parameters, error codes, and other non-volatile data. But it can also be a source of problems if stored values get corrupted.  Here are some good practices for avoiding EEPROM problems and increasing EEPROM reliability.
  • Pay attention to error return codes when writing values, and make sure that the data you wanted to write actually gets written. Read it back after the write and checking for a correct value.
  • It takes a while to write to data. If your EEPROM supports a "finished" signal, use that instead of a fixed timeout that might or might not be long enough.
  • Don't access the EEPROM with marginal voltage. It is common for an external EEPROM chip to need a higher minimum voltage than your microcontroller. That means the microcontroller can be running happily while the EEPROM doesn't have enough voltage to operate properly, causing corrupted writes. In other words, you might have to set your brownout protection at a higher voltage than normal to protect EEPROM operation.
  • Have a plan for power loss during a write cycle. Will your hold-up cap keep things afloat long enough to finish the write? Do you re-initialize the EEPROM when the CPU powers up in case the EEPROM was left half-way through a write cycle when the CPU was reset?
  • Don't use address zero of the EEPROM. It is common for corruption problems to hit address zero, which can be the default address pointed to in the EEPROM if that chip is reset or otherwise has a problem during a write cycle.
  • Watch out for wearout. EEPROM can only be written a finite number of times. Make sure you stay well within the wearout rating for your EEPROM.
  • Consider using error coding such as a CRC protection for critical data items or blocks of data items stored in the EEPROM. Make sure the CRC isn't re-written so often that it causes EEPROM wearout.
If you've seen other problems or strategies that you'd like to share, let me know!

You might also be interested in my blog post on EEPROM and flash memory wearout.

4 comments:

  1. Hi,
    My code for write data and read data to eeprom(AT24C64) is working as per requirements. But instead of AT24C64 i am using now MICROCHIP EEPROM(24LC64) with same code but it is not writing data to eeprom..i have gone through both eeprom data sheet but dont get any difference ,only one difference i got i.e write cycle time
    for At24c64 -wr time 10 ms
    for 24LC64 -wr time 5 ms
    can you help me to solve this problem?

    ReplyDelete
  2. This blog is a bit higher level than that. Since I don't have those particular parts hanging around I can't give you a definite answer. Probably there is something different about them beyond just the timing.

    I'd suggest checking or posting at a discussion board that covers such things. A quick web search revealed:
    http://www.edaboard.com/thread219700.html

    ReplyDelete
  3. Write ahead logging/shadow paging should work well if enough EEPROM capacity is available.

    A simple implementation could use two or more blocks, with each block containing a complete copy of data.

    Each block has a CRC/checksum and a sequence number.

    To load, all blocks are read and the block with the highest sequence number and a valid CRC check is used.

    To write, the block with the lowest sequence is replaced, using the highest sequence number plus one as its sequence number.

    If a failure happens in the middle of a write then that block will be discarded on the next load.

    ReplyDelete
  4. Hi Phil,
    another kind of issue may be EE unexpected wearout due to block writing internal process.
    i.e. you are sure that you're writing a single cell but in fact you're writing an entire 64 bytes page. So writing cycles matter for all things stored in PAGE. It depends on the EEPROM architecture.
    Greetings,
    Daniele

    ReplyDelete

Please send me your comments. I read all of them, and I appreciate them. To control spam I manually approve comments before they show up. It might take a while to respond. I appreciate generic "I like this post" comments, but I don't publish non-substantive comments like that.

If you prefer, or want a personal response, you can send e-mail to comments@koopman.us.
If you want a personal response please make sure to include your e-mail reply address. Thanks!

Static Analysis Ranked Defect List

  Crazy idea of the day: Static Analysis Ranked Defect List. Here is a software analysis tool feature request/product idea: So many times we...