EEPROM/FLASH Writing Cycles Question

[cfernandez]

Hi,

I want to use EEPROM or FLASH for save data, for this memory the datasheet say that the cycle for writing is 100,000 cycles.

1) I can write 100,000 values only for one byte???
2) The write 100,001 is possible that the new value not put in the memory?
3) Somebody know some algorithm for prevent this problem?

thank you very much!!

[Ttelmah]

There is no algorithm to prevent this problem. Sometimes though a 'repeat write', will succeed, but is it showing that a problem is approaching...
Normally the EEPROM memory has typically ten times the 'life' of the flash memory. Recheck the data sheet for your chip.
The figure is not an 'absolute', but a probability. If the manufacturer says (for example), that the life has a 'minimum' of 10000 cycles, aand 'typical' value of 100000 cycles, then depending on their criteria (normally 1%, and 95%), you will find a small number of chips starting to display problems at the lower number of cycles, but most chips will be OK to the larger number of cycles.
A 'cycle', depends on the layout of the memory. If the memory is organised in 16byte blocks, then writing any byte in the block, uses a cycle for the entire block.
Funnily, in terms of 'read life', the best reliability may actually be achieved, by 'rewriting' the contents of the memory at long intervals. However in general the best way to make the memory reliable, is to reduce the number of cycles used. In general the flash memory is designed to be changed at long intervals for reprogramming, or possibly changes to basic configurations. It should not be used for dynamic (rapidly changing) data. The EEPROM memory is desgned for faster changing data, but still not for data that is regularly changed at short intervals. Part of the 'key' to getting good reliability, is to design the hardware and code with this in mind.
For example, I have the EEPROM used to hold the position of a motor on one piece of equipment. This tends to be 'tweaked' usually at fairly short intervals, over a period of a few minutes, then left alone for quite long periods. The code does not write the data to the EEPROM, till the value remains unchanged for thirty seconds. This makes the difference between a value that has to update dozens of times over a few minutes, to a value that is only saved when the tweaking is finished, and may only be written a few times in a day.
As a second example, I have a few calibration values, that are again changing at short intervals on another system. On this, there is a 'power fail warning', triggered when the incoming supply drops by 2v, which still leaves a couple of volts margin to maintain 5v to the processor. When this triggers, the chip cuts all the ancilliary components that draw power (extending the 'life' of the capacitors holding the supply, out to a couple of hundred mSec), and then writes all the configuration data to the EEPROM. It then loops waiting to see if the power recovers. If power recovers, the chips are turned back on, and the system does a 'warm start'. In this case, the data is only written on a 'brownout', or genuine power failure, and often only a few tens of cycles are used in a year.
If you have rapidly changing data, that needs long term storage, look instead at using a seperate memory with better performance and life. For example 'FRAM' memories can be attached using the I2C, or SPI interface, and have faster write times than the internal memories, and life spans in the hundreds of millions of cycles...

Best Wishes