2

What is the best strategy if I have a static value that I want to store in EEPROM once and then be able to read it as far into the future as possible?

Is it better to write it one time and never write to it again, or is it better to periodically (like once per decade) re-write the the value back to the EEPROM to "refresh" it?

Speaking here about modern EEPROM, specially on-board an ATXMEGA which is rated for 100,000 cycles/100 year retention at 25C.

Asked differently, is that 100 year retention specification from the time the the EEPROM is first written to, or from the time the EEPROM was most recently written to?

bigjosh
  • 10,088
  • 32
  • 52

3 Answers3

4

1) Use a forward error correction system which offers to recover from multiple missing bits. Distribute the FEC data across different blocks in the EEPROM.

2) Keep at least two whole separate copies to allow re-writing.

2) Periodically re-read and check for any bit errors. Re-write damaged bits. If they don't re-write cleanly, report an error (how? to whom?)

4) Pay huge attention to your board design and part selection; watch out for rotting capacitors etc.

5) You might want to consider "single event upset" (SEU) rates in the processor: while this is normally only a consideration for aerospace, you're running the thing for much longer.

EEPROMS are floating charge devices. They do leak over time, so I think the retention is from the most recent write cycle.

pjc50
  • 46,725
  • 4
  • 65
  • 126
  • In addition, make sure the EEPROM clock is within specs, within the intended temperature range. Overclocking/underclocking these may damage them physically. – Lundin Dec 11 '18 at 14:56
  • These are all good points, but I don't think they address the fundamental question. If I have n copies and one gets a bad bit, am I better off rewriting the bad copy or not?It depends on what is optimal for a single block. Unless I know how to optimally treat one block, then I can not use data techniques to optimize the longevity of the system by using multiple blocks. – bigjosh Dec 11 '18 at 20:58
  • @bigjosh these “data techniques” as you call them, continuously adapt in real time to the real characteristics of the system within their limitations. Anything else is guesswork. You use the specifications, which are based off incomplete models, to design a large margin of safety around a worst case scenario predicted by those models. Merely assuming the models are 100% correct, is just throwing a dice. – Edgar Brown Dec 22 '18 at 14:13
0

In practice, your best bet is to buy a much larger EEPROM and periodically rewrite the data into a different portion of memory. Cuts down on erase cycles, and most EEPROMS are much larger than needed anyway.

Cristobol Polychronopolis
  • 10,599
  • 10
  • 18
  • So you are saying treat the EEPROM as an append only WORM device and periodically rewrite the data at the tail of the last write? Make sure the last byte of the data block does not contain an 0xff and then when reading the data, always start at the end of the EEPROM and scan backward looking for the first non-0xff to find the most recently written block? I've see there are can be problems with writes to EEPROM blocks impacting adjacent blocks, would you not expect that to be an issue here? – bigjosh Dec 11 '18 at 20:51
  • @bigjosh, I'd expect less problems with this approach than repeatedly rewriting a single location. – Cristobol Polychronopolis Dec 12 '18 at 15:47
0

Official word from Atmel is that the 100 year retention period begins with the first write to each EEPROM location.

This would suggest that to persist EEPROM data as far into the future as possible that you should....

  1. Ensure that the data block is not all 1 bits using escaping or bracketing if necessary.
  2. Write the block of data at block location 0 on year 0.
  3. Write a copy of the the data at block location 1 on year 100.
  4. Write a copy of the the data at block location 2 on year 200. ...etc...

To read the stored data out, start at the top of the EEPROM address space and read blocks backwards as long as you see only 1 bits. When you see a block of data that has at least one 0 bit in it, use that data.

Note that if you need to update the data, you can update in place at the same location for the first 100 years and first 100,000 write cycles before moving on to virgin EEPROM locations.

Quoted conversation with Atmel below...

Created By: Abirami Sivakumar (12/21/2018 6:16 AM) Hello Josh,

Yes your understanding is correct.

The erased condition of EEPROM is 0xFF. From the factory it is completely erased and manufactured. So if you are writing some value to the particular location, the corresponding value will remain after 100 years.

Best Regards, Abirami Sivakumar. Created By: Josh Levine (12/13/2018 12:46 PM) This makes sense. So a device received from the factory has EEPROM filled with 0xff.

If on year 1 I write a 0x00 to a location in the first block, then I would expect that 0x00 to be readable at year 100 .

If on year 100 I write a 0x00 to a location in the second block, then I would expect that 0x00 to be readable at year 200.

Is this understanding correct?

Would you expect an programmed EEPROM location with a 0xff from the factory to remain readable as an 0xff indefinitely?

Thank you!

-josh Created By: Abirami Sivakumar (12/13/2018 6:58 AM) Hello Josh,

Thanks for contacting Microchip Technical Support Team

Data retention time starts from first time to the EEPROM location.

Hope this clarifies. Please let us know if you need further clarification.

Best Regards, Abirami Sivakumar.

bigjosh
  • 10,088
  • 32
  • 52