Microchip now seem to be recommending, for on-processor-chip EEPROM, to refresh the contents periodically (which they define) if the memory usage exceeds some fraction (10%?) of the expected life. The implication is that with large numbers of writes the retention time decreases substantially before you get outright failure.
Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
I recall an article, maybe from EDN, On allocating a 'Block' of eeprom memory and incrementing thru this block. Thus if you need to write a 1 byte counter, you have N number of bytes to write it in. Figure on two writes for each byte, one for the counter, and one for the erase at the end of the block. You need to erase the block once its full so you can traverse the block to find the last written byte. And you cant write a counter of 0xFF, other wise you will loose the last block position
So the endurance would be (ee_endurance * Block (N)) / (number of writes)2
For a four byte array (N) you would double the endurance.
Martin
Vladimir, he specifically said "counter". To me, that implies that he's planning on changing the value EVERY time he writes it, and it also implies that he wants to see EVERY value. *IF* he has a good power-down sequence, and *IF* he has a good power supply that will keep everything alive and stable long enough, THEN it makes sense to do write-behind caching. In my experience, those are two very big IFs. With the modern preference for switching power supplies, as opposed to the old huge heavy(!) linear supplies with filter capacitors the size of vodka bottles, I would not want to rely on very much time at all after the power-down warning came.
It seems to me that this "fading" is directly related to the EEPROM write/erase duration (1,000,000 in your case). For EEPROMs it represents the breakdown of the floating gate barrier that maintains charge retention. However for any variable data that is stored on non-volatile memory I would think that some form of data integrity check (checksum, CRC, etc) is required.
Caching of the data in RAM has been suggested in this thread and this may be the most appropriate way of extending EEPROM life -- unless you really want 8 million power cycles as a requirement!!?
For a 2-wire or I2C EEPROM it takes about 10 milliseconds to perform a byte or page write. A page is typically 64 bytes so this means that you can write 64 bytes (in the same row) in 10ms -- for your requirement this should be adequate to store the counter value with CRC or checksum. Allowing for other overhead, your requirement to the Power Supply guy should be about 40 millisecond retention on the 5 volt supply (this is conservative). This should be achievable, even with switching supplies.
Of course, your power-down sequence should be so that if promotes the extension of power by: o turning off all LEDs & displays o turning off all backlights o switching off any motors & stopping any PWM drives
+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.comHello Robert,
Take a look at Microchip's application notes AN537 (and AN536 and AN
602). They give you a bright idea about what endurance is and how to get most out of your EEPROM.Aart
Robert Scott wrote:
fake.)
Good suggestion. I found this in AN537:
"Indeed, this write all ?0?s test pattern will produce very different results than a checkerboard test pattern of alternating ?1?s and ?0?s within a byte, since cells are changed more often writing all ?0?s than in an alternating ?1? and ?0? write pattern."
This seems to confirm that not all writes are equal, and that there may some value to implementing a counter where the transitions from "0" to "1" are delayed as long as possible so as to minimize the number of bit changes.
-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.