please dont rip this site

Extending lifetime and reliability in EEPROMs

Dwayne Reid of Trinity Electronics Systems Ltd Edmonton, AB, CANADA says reguarding a data logging application:

When the system powers down, all I have is the data stored in eeprom. I am currently using 8 records of 32 bytes each in the buffer - another record is stored at some time varying from 1 minute to an hour.

Each record includes a CRC to warn me of a corrupted record or damaged eeprom. If a damaged sectoin of eeprom is found, I swap in one of 7 spare chunks (just change the pointer in my 'housekeeping' section.

Essentially, I consider any location that gets written often to be subject to damage. Thats why I don't keep my buffer pointer in eeprom - it would have to be written every time a new record was written - and, if that location died, I would have no way of dealing with it. The way I have it set up now, my housekeeping section get written once upon first power-up, then written only when necessary to map out a defective section of eeprom. Each of the 8 records currently in use contains the 1 byte sequence count - I simply need to find out which count is highest so that I can set my buffer pointer to that record.

I start off with 512 bytes of eeprom. This is divided into 16 chunks of 32 bytes each. One of those chunks is reserved for what I call 'housekeeping' - it contains 3 copies of the start addresses of the 8 records in my buffer. This leaves me with 7 spare chunks of eeprom that will get swapped in as required. When the last of those is gone, my buffer drops from 8 records down to 7, then 6, etc. Of course, when I have lost more than a couple of spare chunks, I'll signal that maintenance is required.

Wagner Lipnharski says that to allow eeprom to store data in a buffer reliably:

a) If you have an extra byte at the eeprom, just save the last IDentification block number there, or circular buffer pointer, so when you power up again, just read it and set the buffer pointer back, or search for the ID into the circular buffer.

b) If you DO NOT have this extra byte, or don't want to keep reducing the eeprom life, just reserve the "00" identification byte for the next empty block, use block ID's from 01 to FF. Whenever you write a block, write an extra byte of "00" after that block, *that* will be your mark of END OF CIRCULAR BUFFER. For sure this "00" will be recorder over the oldest block identification byte, but even so you would be able to read that block of data.

With this option, at power up, you just need to go to the beginning of the circular buffer, and start reading just the block ID's, looking for "00", so the most recent is exactly the previous one, the oldest the one with the "00".

Any other math solution doesn't work, since if your block ID's are also circular from 00 to FF, there is NO WAY to find out which one was the last, except in one condition:
If your circular buffer size is not a perfect multiple of the (block data size + Id) * 256. In this case you can search for a disrupt in ID sequence. For example, if you circular buffer is only 256 bytes long and your block size is 32 bytes:

ID  DATA (31Bytes)- - - - - - - ->
01  00 01 02 03 04 ... 1E --- begin of circular buffer
FD  00 01 02 03 04 ... 1E
FB  00 01 02 03 04 ... 1E
FC  00 01 02 03 04 ... 1E
FD  00 01 02 03 04 ... 1E
FE  00 01 02 03 04 ... 1E
FF  00 01 02 03 04 ... 1E.
00  00 01 02 03 04 ... 1E --- end of circular buffer

If the block size is fixed, then you see that the difference between two block ID's is different than 1 [ed: subtract and ignore carrys] it means the lower address block is the last one, if the circular buffer runs up address. In this example it is clear that the [record ID # 01] is the first on the buffer.

Again, this technique will not works if your circular buffer holds only 2 blocks, or its size is exactly the block size times 256 (to a 8 bits ID), so the disruption above 65 -- 62 would then be 65 -- 66.

Now, if you really don't need to store the block ID number, then: If the first data byte values follows some kind of rule, for example, it is always less than 7F, you could use the bit 7 turned on only for the next buffer available byte, so easy to scan when powering back on. Or if the data bytes never use some bit combination, use that combination at the next buffer available byte.

In any way, you need to remember that you have a limited quantity of write operations in the eeprom chip. There are eeproms for 100k or 1M recordings (never clear from manufacturer, temperature changes it)...

Ruben Jvnsson [ruben at pp.sbbs.se] of AB Liros Elektronik says:

I'm currently working on a project which includes a 24LC16B I2C EEPROM and a serial RS485 connection. The communication on the serial connection includes commands to directly write and read the contents in the EEPROM. When developing the software, I did a testprogram which constantly, by commands on the serial connection from a PC, writes a random value to the EEPROM and verifies that it can be read back. There is a counter which keeps track of how many times this has been done. The PC also writes a log-file where I can see any errors that has been detected (serial comm errors, eeprom verification error). I have run this routine at nights and weekends to see when the EEPROM failed. At first I thought there was something wrong with the software because the EEPROM never failed. But at last, this weekend, after about 12000000 (twelve million) write cycles to the EEPROM i started to get verification errors. This took a couple of weeks since the serial connection is only 2400 bps.


file: /Techref/mem/eeprom/relylife.htm, 6KB, , updated: 2008/2/1 13:58, local time: 2024/10/13 00:20,
TOP NEW HELP FIND: 
35.171.164.77:LOG IN
©2024 PLEASE DON'T RIP! THIS SITE CLOSES OCT 28, 2024 SO LONG AND THANKS FOR ALL THE FISH!

 ©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions?
Please DO link to this page! Digg it! / MAKE!

<A HREF="http://piclist.com/techref/mem/eeprom/relylife.htm"> Extending lifetime and reliability in EEPROMs</A>

After you find an appropriate page, you are invited to your to this massmind site! (posts will be visible only to you before review) Just type a nice message (short messages are blocked as spam) in the box and press the Post button. (HTML welcomed, but not the <A tag: Instead, use the link box to link to another page. A tutorial is available Members can login to post directly, become page editors, and be credited for their posts.


Link? Put it here: 
if you want a response, please enter your email address: 
Attn spammers: All posts are reviewed before being made visible to anyone other than the poster.
Did you find what you needed?

  PICList 2024 contributors:
o List host: MIT, Site host massmind.org, Top posters @none found
- Page Editors: James Newton, David Cary, and YOU!
* Roman Black of Black Robotics donates from sales of Linistep stepper controller kits.
* Ashley Roll of Digital Nemesis donates from sales of RCL-1 RS232 to TTL converters.
* Monthly Subscribers: Gregg Rew. on-going support is MOST appreciated!
* Contributors: Richard Seriani, Sr.
 

Welcome to piclist.com!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  .