Reading EEPROM wear it out?

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey, just a quick question. Does reading the EEPROM in your program contribute to it's 100,000 (or whatever) cycle lifetime?

- Dean

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No. Make an EEPROM counter (use two locations?), when counter reaches 100.000. Put a message on an LCD: Replace AVR :roll:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No. The DS talk about "Write/Erase Cycles".

And @RoBSki:

Quote:
Make an EEPROM counter (use two locations?), when counter reaches 100.000.

I assume "two locations" means two bytes. How do You make a counter that reaches 100.000 of that?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, 65535, so it's 3. (16777216 max count)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guys, there is no reason for him to place a counter into eeprom that counts to 100,000.

The EEPROM will more than likely surpass 100,000.

What needs to be done is his eeprom write routine should *verify* the data that has been written and never erase/write a byte that is the same.

Most people code their eeprom writing routine to always write the value regardless of the prior contents.

the following steps should always be used:

1.) Is the contents of the cell to be written the same? If so, exit the routine.
2.) write the new value
3.) read back the contents of this location through an eeprom read.
4.) are they matched? If not, send an error message or retry the burn again and it may go.

If step 4 fails, your eeprom is at it's end of life or their is a voltage stability issue, etc.

On newer AVR's, I'ld swear I read you could tell the EECR whether or not to erase the cell prior to a write????

If this is the case, you should check if you can OR the bits into an existing cell to avoid the erase cycle saving you a count of +1 burns to that cell.

Regards