Max EEPROM erase cycles using write/read_eeprom()

[caddy]

Hi

I know for most PIC 18s that the maximum number of writes to the EEPROM is around 1,000,000.

What I am wondering is, is this per byte? Ie, if there are 1024 bytes in the EEPROM, can I write each byte 1,000,000 times (totalling 1024*1,000,000), or do I just get the 1,000,000 writes in total, regardless of where the destination is?

If its the latter, is there any way, using CCS functions, that I can write more than one byte in a single cycle?

Thanks

[Ttelmah]

OK. First thing, for reasonable reliability, always use the 'minimum' figure in the data sheet. Otherwise you will get the odd chip that gives problems well before the 'typical' figure.
It is 'erase/write' endurance. On the EEPROM, when a cell is written, it is automatically erased before write. This is done on a 'per cell' basis. This differs from the program memory, where a whole 'block' is erased.
However there is a separate specification that comes into play, with data that is changing, which is "number of total erase/write cycles before refresh". Basically, you have a reliable total number of cycles of 1024*100K (using the minimum spec, rather than the 'typical' spec), but after the 'number of total erase/write cycles', the whole contents should be refreshed (read, and written back). This is because there is a fractional leakage as cells are erased/written, affecting all the other cells in the memory. This is typically 10* the individual cell life.

Best Wishes

[caddy]

[Ttelmah]

Take the 18F2525 as an example. In the data sheet, table 26-1, you have the predicted best case life for the byte, of 100K cycles. So changeing the byte being used, you have a total of 1024*100Kcycles. But specification D124, gives the refresh required value (1M min), so after writing just 10*100K values (using 10 bytes to their limit, or the whole memory, taking perhaps 1024*1K operations), you then need to refresh the _whole_ memory. The refresh, is needed to actually reach the expected 'per cell' life, based on how many writes have been performed to the whole memory. So to get the full life, the memory will need to be refreshed 100*, to reach the expected total life.
Consider seriously, approaching this a different way. If you have a value that is changing a lot, keep it in RAM. If the power fails, _then_ save it to the EEPROM. It is relatively easy, to add a supply level detector circuit, to say that the incoming supply is failing, and write the value at this point. You can even have it write on a watchdog restart, if the value in RAM doesn't match the value in memory as well (do this before variables are initialised), this way, if the system crashes, it also writes the value. I did a counter system like this some years ago, which if the count was written on every operation, could have used the EEPROM life in a very few days. Some of these have been running continuously for several years, without problems.

Best Wishes

[valemike]

[Ttelmah]

FRAM is a good solution.
However the key is how fast can you turn off the relays. Are these 5v?.
If they are not 5v, then you can use a supply supervisor IC on the higher rail, for earlier detection. However if there is enough capacitance to give a reasonably smooth supply with the load of the relays, if you turn these off (and every other peripheral in use), you will generally find the supply capacitors then provide plenty of 'write time'.
Remember that the time to droop one volt, is calculable. Taking a typical PIC, that perhaps draws under 20mA when running on it's own, 0.4mF, will give 1/50th second, for the supply to fall 1v. Given that the rails will often have 470uF (0.47mF), and that you can write 5 bytes in this time, achieving the hold-up, is not hard. Your write code, should then stop, and simply loop monitoring the voltage. If it recovers, then a clean 'restart', without actually stopping operation, should be triggered.

Best Wishes

[valemike]

Yes they are 5V, SPDT relays. I'm going to have to experiment with eeprom saves during brown-outs, under heavy load, and see if i can get reliable data saves over several trials.

Since we're on the topic of internal eeprom, do you occasionally encounter some units whose certain eeprom bytes just don't get saved properly?

I've encountered 1 out of 50 units that do so. In such an event that the value read from eeprom is an unrealistic number (i only accept a range of 1 to 10), then I switch to default operating values.

[JimHearne]