Load Leveling EEPROM
mynet43
Posts: 644
I have an application that stores calibration and position data to the Prop's eeprom (above code space). The application moves an X/Y table under an electron microscope with very high precision, using a trackball and touch screen. The program has to save the location after each move, so it can recover if the power is switched off.
Here's the problem. The typical eeprom is only guaranteed to work for the first 100,000 store cycles. If the customer makes 1000 moves per day, the eeprom may stop working after about 100 days.
Has someone already developed a load leveling algorithm for the Prop eeprom. I'm only storing a small amount of data. I think I know how to do it, but I'd rather not re-invent the wheel if someone already has it.
Thank you for your help.
Jim
Here's the problem. The typical eeprom is only guaranteed to work for the first 100,000 store cycles. If the customer makes 1000 moves per day, the eeprom may stop working after about 100 days.
Has someone already developed a load leveling algorithm for the Prop eeprom. I'm only storing a small amount of data. I think I know how to do it, but I'd rather not re-invent the wheel if someone already has it.
Thank you for your help.
Jim
Comments
John Abshier
It's too late for a hardware change. The board is already designed and working.
I do have a question. I haven't looked at the spec sheet on that chip. Is it compatible with the Prop eeprom electrical interface? If so, it would make a good substitution. If not, just a thought...
Thanks,
Jim
John Abshier
I never use anything but surface mount if I can find it.
Determine the free bytes you have, and determine how many bytes you need to write. If the free bytes/bytes to write * 100k is a sufficient number of days/months, then you can spread the writes out over time. Set a variable and eeprom address as an counter value (long). When the counter hits 100k writes, bump the whole set of addresses up by the number or req'd address including the counter.
X address (?size)
Y address (?size)
Counter address (long)
If counter > 100k then ADD a value to the address field in the eeprom write method ie
address + offsetVal(counter)
You could also use a method of testing the writes to eeprom to see if the results read back the same as what was written warn or automatically update the offset value to bump the writes up to the next available address.
If there are not enough free addresses to serve you purposes ( days, years etc ) then it may not be too hard to stack another eeprom on top of the other, just tweak the address pins. This way you can bump to the next eeprom after that one fills up.
You can also replace the eeprom with a larger size and make no other changes and that will buy you many times the write locations.
If you have 32k free bytes and are writing 2 longs, and there was a long for the counter:
32768 / 12 bytes = 2730 possible write locations.
1000 writes per day
100 days per location
100 days * 2730 write locations = 273000 days or 748 years
What I have done is something like this -
If you need 6 bytes of storage, set up a block of 4+(depending on how much wear leveling you need) storage sets, but add two bytes to the six for a total of 8 bytes per set, and 32 total.
On initialization, set the top 2 bytes of each set to 0xFF or something.
When you write a set you first check the top bytes to see if the set has been written, if so, then you set the top two bytes to 0 and the lower bytes to your value. If not, increment to the next set. If all are full, reinitialize all and start at 0.
On reads, start at the top and look for the last written location.
I checked with Ramtron and it looks like the FM24V05 is pin compatible with the AT24C512, which I'm using. If so, I may be able to just substitute it on the board.
The problem is I need a solution this week.
I'm thinking I can dedicate the 1st 4 bytes of storage to the address of the current data. Then each time I power up, I can read the data and increment the storage location by the amount of storage. Then write the new address back and store the data in the new location. This would be used for the current run. If it reaches some upper limit, then wrap back to the original starting address.
Does anyone know if the data blocking of the eeprom would make this fail? I.e., do I need to increment the address to the address of the next storage block?
Thank you for your help.
Jim
When the first 4 wear out, then what?
Why not just do a round robin approach? Set a specific 'sync' that would be unique to any of the data being written. Example a data logger I worked on, I skewed the data so that 254 was the highest possible number it could generate. With that in mind, each 'new' data entry that it wrote would start at the location of the last place 255 was located and be followed by a 255 sync to signify the END of data. While the unit was powered it kept track of the 'location pointer', but if the power was to go out or be cycled, a quick initialization routine searched for the 255 within the memory to determine where it left off. Basically it functioned as a non-volatile FIFO.
You asked what happens when the 1st four bytes wear out. These are only changed when the system is booted. So to wear them out, you would have to power-on the system 100,000 times. I think this would be labor intensive
@ Beau,
Thanks for the info on how you did it. I'll evaluate that as an option. It may not be any easier than saving the starting address and wrapping the records at a max location.
Thanks to everyone for the great responses. It sounds like no one has working code available. I'll try to write it for somewhat general use and post it if it looks worthy.
Jim
Has anyone tried this or a similar chip to see if the timing and blocking are compatible with the AT24C512?
I'll try it when I get it to see what happens.
Jim
Humanoido