View Full Version : EEprom question or a Clock answer?
01-09-2009, 11:54 AM
So I have read about the EEProm wearing out, but how much can I toss at it? I want to write to the EEprom every hour that my device is turned on. I want to write to the same address location and want to know if this is acceptable, or will after a month it wear out. I am looking for a 10-15 year life cycle on this device.
If it is not a good idea then how can I keep a log of how many hour my device has ran. This way if a customer returns my product I will how long the device has ran.
01-09-2009, 12:25 PM
Each manufacturer quotes a minimum number of writes for each location. You know who's making the EEPROMs you are using. Read the datasheet. You know how often you want to write. You can do the arithmetic.
It would be much better to spread out the information across the whole EEPROM and avoid the wear issue. Assign a set of locations for each hour in the day and each day in the year from the time the device was initialized. Since EEPROMs are initialized to $FF, your program can tell if a location is not initialized. If you have 2 bytes (a 16-bit word) for each set of locations and some kind of timer to tell when an hour has passed, you search the 366 x 24 words for the highest value that's not $FFFF, then store that value + 1 in the next word (wrapping around to the start of this table if necessary). If all the locations have $FFFF, store a $0000 in the first location.
If you want to store data as well, allocate several bytes to each table entry and use the extra bytes for the data. We're talking here about 10K for the counters. You could even use just a 24 entry table. It would take a very large number of hours to wear out the EEPROM.
Post Edited (Mike Green) : 1/9/2009 5:43:29 AM GMT
01-09-2009, 03:55 PM
5 bytes (same locations) are enough for your target (27 years) even in the worst eeprom case (10k rewrites)
Since the eeprom wear only on bit initialization (when there is a need to restore a 0 in 1) you can use 3 bytes to track the 24 hours in a day by progressively togling the 24 ones to zeros (one wear per day) and one word (two bytes) as integer to track days (again one wear per day) 10K writings = 27 years
01-09-2009, 07:29 PM
Microchip has an interesting idea that greatly increases an eeproms effective endurance. To implement it with an eeprom, you would have to use two bytes per byte stored. The second byte value is the effective eeprom address. The first byte value is the value to store. Each time there is something to save the eeprom address is incremented to use the next address. The program looks backwards and reads the last value entered for that address. Another way to implement this is to create a block that increments each time you store it, then loops back to itself and overwrites itself.
The simplest solution is the $1.19 4k fram which allows you to store 512 bytes of value every second for (100's years?) This can be added right to the program eeprom pins.
01-09-2009, 11:49 PM
Speaking of fram this devices used instead of prop boot eeprom will replace it, solve your problem and add other hardware features like unique ID, RTC, hw counters (I have used them wired on photodiode and chassis swich as a encription key: you preset the key, if the box is open the counter increment and the key changes)
01-10-2009, 12:48 AM
Erik provides an interesting solution - FRAM, "Ferroelectric RAM". Allow me to expand on Erik's post...
More on FRAM or F-RAM here...
RAMTRON makes FRAM devices that are variously addressed (serial included). Look here:
These RAMTRON FRAM parts are low-cost and readily available even in unit qty.
from the online distributors (search via www.octopart.com (http://www.octopart.com)).
I see these FRAM devices as nice solutions for highly repetitive static reentrant storage of data for reboot configuration of CPLD and/or FPGA type devices.
There are NV-SRAM devices from the likes of Maxim-Dallas and others that offer SRAM with on-chip or external Li-Ion backup battery that lasts 10 years (on-chip) and has unlimited write cyclea.
Also consider external flash storage via higher-end SD cards that have wear leveling built-in; this dramatically and transparently increases traditional flash storage write-life. In production, the likes of a SD card may be available for placement on a PCB, but I've never seen such form-factor readily available in small quantities.
Best Regards, David
Bob Lawrence (VE1RLL)
02-14-2009, 03:17 AM
Links not working .
02-14-2009, 03:47 AM
I am about to order the FRAM memory IC, but frankly I am a bit concerned. The data sheet shows that the 24LC256 is 32k x 8 where the FRAM is 512 x 8. Will this make a big mess in conjunction with the propeller. My intention is to replace the 24LC256?
Fram data sheet - http://www.ramtron.com/files/datasheets/FM24CL04ds_r3.0.pdf (http://<b>http://www.ramtron.com/files/datasheets/FM24CL04ds_r3.0.pdf</b>)
Micro data sheet - http://ww1.microchip.com/downloads/en/DeviceDoc/21203M.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/21203M.pdf)
Yes, the one you have chosed won't work: it's only 4KB
You need this: http://www.ramtron.com/files/datasheets/FM24L256ds_r1.1.pdf
or with some more features this: http://www.ramtron.com/files/datasheets/FM31L27x_r2.0.pdf·(FM31L278)
both can replace the prop eeprom
02-14-2009, 04:02 AM
Ramtron makes a "drop-in" replacement for the 24LC256, the FM24C256. They even make a 64K x 8 version, the FM24C512. They're both 5V devices, so you'll need to be careful about the Propeller 3.3V I/O pins. I2C uses an open-drain output, so the pullup resistor will protect the Propeller I/O pin. You need to use a pullup of at least 10K. You could also use other I2C voltage translators as described in the "sticky" thread about "Propeller Hardware Stickies".
The FM24L256 is a 3.3V part and would interface directly with the Prop with no voltage issues. I don't believe there's an FM24L512 yet.
All of these parts are available only in SOIC-8, but there are nice adapters available for PDIP usage from SparkFun and others.