I plan on using the EEPROM to store about 2 integers of "reboot" data. In my research, I saw the 100,000 write limit on EEPROM. This would mean My applications/controller could possibly have 100,000 writes after 18 months of use and fail.
I want to verify what this means:
Does the 100,000 limit of writes mean the entire memory map will fail after 100,000 writes.
Or
Does the 100,000 limit of writes mean each BYTE of memory have 100,000 writes before fail.
If it is the latter (100,000 per byte) then I can simply "write" a moving address across the memory after 90,000 writes to one address then, I can float my writes across the entire memory map. Meaning it will last longer than the user of the application/controller.
I asked myself the same question.
It is not the whole EEPROM, it is each byte that can do up to 100,000. But that is just a very rough number. You can't assume that 90,000 is okay. I read somewhere (perhaps the datasheet ?) that it depends on the temperature.
I think it is a single bit that fails, and the other bits can still be written. I'm not sure about that, I wanted to make a test, but I'm busy with other things. I also don't know if that faulty bit stays high or low.
You can spread the writes across the memory. But you can't store the index in the first EEPROM location. So you have to think of something to find the latest data. I use that spreaded writing in one of my ATmega8. Each update is stored in the next location.
Look at the EEPROM as if it is a ring-buffer. Store the data in a new location, and make the data in the oldest location invalid. So you can search for the newest data with the next start. Or use a counter in the data.
18 months... is that an update every 7 minutes ?
Perhaps you have a ATmega328P, that is 1kbyte EEPROM. Two integers is 4 byte. So you have 256 positions. That is 256 * 18 month = 384 years. Suppose you make the oldest data invalid (extra write), so you have 192 years.
In keeping it simple and iterative, it looks like I should use a "round robin" moving address method of writing to reduce odds of errors. I guess I should figure 1 in 512 getting an error. I will use the first two bytes to contain the address of fresh data location. The good news for me is the user of the controller will not always use this method to save data. So it is only going to be 30% chance of the memory feature being turned on.
ONE more question comes up:
I didn't look but I suppose there is an error code on write?
Or, do I build my own functional trap. (IE... write, verify, re-write if fail verify)
Crossroads
Link was great.
I will be building an ICB eventually and will make sure there is room to mount the memory chip.
Looks simple to use and will be easy to integrate. Should be a fun project.
I have another wireless project coming up. This memory chip would be better.
Plus, it will last a bit longer "TRILLION"
Thanks again for the help.
I have moved from a busy collaborative lab to working out of my home. I do miss the collaboration and find it refreshing this forum has contributors like you all. I only hope to help out as I move from NUBE to actually a real contributor.
No error return when writing EEPROM. If you have to be sure, you can write your own functions. I would use a checksum with the data.
Are you going to use EEPROM location 0 and 1 for a pointer to valid data ? ha ha ha, then you could just as well write the data itself into location 0 and 1. That is what I ment when I wrote that you can't store the index in the first memory location.
When a EEPROM byte is failing, will it fail forever, or could data still be written after some time, or will the read data be different if for example the temperature changes. So many things I don't know...
When a EEPROM byte is failing, will it fail forever, or could data still be written after some time, or will the read data be different if for example the temperature changes.
In cryptic disclosure here is the application: (NDA is in place)
In this application the controller has 4 buttons the user pushes. The client has purchased 20 controllers that have 500 growing to 1 million button pushes yearly. So my simple math was 1,000,000 / 20 or 50,000 pushes per controller per year. (with some controllers being used more than others)
I am storing the number of pushes as well as the max pushes per controller (varies from time to time). If the max pushes equal the current number of pushes then I disable the controller and it will need to be "Refreshed" Each push is payed for but the users of the controllers. Basically the users prepay for X pushes. When the controller reaches X the user needs to prepay again for X more pushes.
In reality the 100,000 writes will be 3 to 5 years and if I use the moving memory as suggested I don't see this an issue anymore. I just wanted to make sure it was each BYTE not the entire memory map. Peter, I bet as you suggested it is a BIT or two per BYTE that has issue. Electricity is like water. It can wear out what it flows through.
I figured I could store in address 0 and 1 a value 1 to 512 That value could then point me as an offset in my next read
For example: (without syntex or integer/byte logic)
MAX_cnt = 100 and is stored in location 12 - eeprom address (0) has a value of 12
CUR_cnt = 50 and is stored in location 13 - eeprom address (1) has a value of 13
I also think it is per bit. The failure mechanism has to do with the dielectric between the gates slowly becoming contaminated with trapped electrons. Eventually the difference between a "1" and "0" narrows to where they are indistinguishable. What level that reads as I don't know. While the gate can lose its charge over time (it takes many years for data failure in this way) I don't think the electrons trapped in the dielectric can leak away.
Atmel claims an endurance of "at least" 100,000 writes for the 328 processor but I have not seen where they state the temperature. Do they mean at 25°C? Or do they mean worst case of maximum operating temperature? At 85°C you get about 1/3 as many write cycles as at 25°C. On the other hand, if you can arrange to chill your processor to 0°C you can gain about 2/3 more cycles.
Interestingly Atmel's other EEPROM products come with a claim of 1,000,000 write cycles.
The 100,000 is a guaranteed limit. In practice it seems to perform for MUCH MUCH longer. I've seen many folk that have tested to destruction. Invariably it lasts well into the millions.
Just writing and re-reading the EEPROM does not prove it is still working, it may forget the byte a few minutes or months later, so I would stick with the guaranteed lifetime.
To the OP: You do not need to have an address pointer. Just define some "magic number" e. g. 0x00. Write your data to the first n EEPROM addresses, then write the magic number to address n+1.
Of course your data must not contain 0x00.
When it is time to update the data, overwrite the magic number and continue writing to consecutive addresses, always appending 0x00.
When the controller reboots, scan the EEPROM for the first 0x00 and continue writing there.
You have to implement some wrap-around counter for when you reach the end of the EEPROM
olf2012:
To the OP: You do not need to have an address pointer. Just define some "magic number" e. g. 0x00. Write your data to the first n EEPROM addresses, then write the magic number to address n+1.
Of course your data must not contain 0x00.
When it is time to update the data, overwrite the magic number and continue writing to consecutive addresses, always appending 0x00.
When the controller reboots, scan the EEPROM for the first 0x00 and continue writing there.
You have to implement some wrap-around counter for when you reach the end of the EEPROM
Thereby halving the shelf life of the EEPROM as you're doubling the number of times you write to it.
krisk, when you have the offset in location 0 and 1, you have to write that every time you store the data somewhere. So location 0 and 1 are written just as much as data is written. You are spreading the data but the offset will wear out.
Since you have an always incrementing CUR_cnt, it isn't so hard to do. The EEPROM would be like an array of 2 integers. When the power is turned on, search for the maximum CUR_cnt and use those. Remember the index and use the next index to write in. At the end of the EEPROM, rollover to zero.
To use the EEPROM as an array of two integers, you could use the EEMEM keyword, or calculate the offset, or use a struct with 2 integers, or use a dword to read and write EEPROM (eeprom_write_dword) and combine and split the integers in a dword.
krisk:
could possibly have 100,000 writes after 18 months of use and fail.
Just to put this into perspective, You are planning to have your robot running non stop for 18 months and writing the settings to eeprom every 5 minutes?
Do the math:
We have 1024 bytes, each of which can be written to 100000 times, that's 100 million bytes written.
If we write ONE byte EVERY minute, we get a lifespan of 100,000,000 minutes = 194 years. If we double the data size we get half the lifetime = 97 years. If we reduce writing speed to one operation every five minutes we get 5 times the lifetime = 487 years.
I would consider any device that is designed to last more than 30 years "excellent engineering"
That FRAM looks amazing!
Fast, virtually unlimited rewrite capability, fairly large capacity, small package, low power, long (albeit, at 151 years, oddly specific) data retention...
KenF:
Just to put this into perspective, You are planning to have your robot running non stop for 18 months and writing the settings to eeprom every 5 minutes?
It is not a robot, it is a controller with 4 buttons. The user will turn it on and push the buttons. The devices it controls results in 500,000 button pushes per year today and within 2 years 1,000,000 button pushes. There will be 20 controllers with 4 buttons each.
Basically, I figured each controller will receive 50,000 pushes per year. Meaning I will be recording not only those 50,000 pushes but a programmed "MAX" amount that disables the controller if the user push more than he is allotted.
I might be overthinking the 100,000 limit based on the experienced responses here.
I also know I need to do some more research on how to store the two int's into the EEProm memory
I will probably work another iteration with FRAM it looks like the sure fire way to store simple data in memory (Foreveeerrrrr)
Do you really have to save to eeprom after each and every button press? I take it that you're trying to ensure that, in the event of a power outage, it will resume exactly where it left off.
olf2012:
Do the math:
We have 1024 bytes, each of which can be written to 100000 times, that's 100 million bytes written.
If we write ONE byte EVERY minute, we get a lifespan of 100,000,000 minutes = 194 years. If we double the data size we get half the lifetime = 97 years. If we reduce writing speed to one operation every five minutes we get 5 times the lifetime = 487 years.
I would consider any device that is designed to last more than 30 years "excellent engineering"
So I see your logic but that wasn't how I interpreted it. If I write a value to byte at position 1 it will be good for 100,000 writes. So using the fact that a controller I have can record 50,000 button pushes in a year plus the MAX (value) setting, I have less than 2 years of guaranteed writes.
I need to noodle on your logic OLF. It basically says I don' t need to worry. However if my controller breaks in less than 2 years because of this 100,000 issue I will have a lot of expense repairing/replacing the chip.