7
\$\begingroup\$

We have an EEPROM with a 10,000 cycle life duration - Our application may write more than 10,000 times.

If we write to the same location over & over, is it only that single location that potentially fatigues and fails? Or would the failure extend over multiple cells?

I'm thinking an easy way to get round the limit is to dedicate 10 memory locations and use a rotating pointer. That would (I think) increase my potential write cycles 10x before it becomes an issue.

Am I heading down a good path, or is this totally the wrong thing to do?

Many folks are wondering why I don't just use another part, or one that's better documented. The EEPROM is built-in to this one. In our business, we're locked into a few suppliers who make very specialized ASIC's and who don't document their chips such that I can just read this in the datasheet. Their engineers all speak English as their 3rd or sometimes 4th language, so asking this kind of question is usually quite difficult and answers always taken with a grain of salt. They make up for these annoyances by selling stupid low cost chips. We have micro's available to us that cost about 3 cents each (no exaggeration). Most of our IC's are about $0.15.

\$\endgroup\$
11
  • 4
    \$\begingroup\$ Where will you store your pointer? \$\endgroup\$
    – Graham Nye
    Mar 9, 2021 at 19:35
  • 1
    \$\begingroup\$ Useful search term : "wear levelling" : your suggestion is a primitive form of wear levelling. \$\endgroup\$ Mar 9, 2021 at 20:13
  • 2
    \$\begingroup\$ You may be interested in this answer (electronics.stackexchange.com/a/515008/78538) which shows the hell that eeprom failures can cause, and how hard it can be to debug them \$\endgroup\$
    – BeB00
    Mar 10, 2021 at 2:10
  • 4
    \$\begingroup\$ Am I heading down a good path, or is this totally the wrong thing to do? – Congrats, you just invented dynamic wear leveling! \$\endgroup\$
    – forest
    Mar 10, 2021 at 7:26
  • 1
    \$\begingroup\$ Just wondering, what supplier are you working with? I'm a big fan of stupidly cheap electronics! \$\endgroup\$
    – crossroad
    Mar 15, 2021 at 21:20

5 Answers 5

18
\$\begingroup\$

EEPROMs don't wear out from writing, they wear out from erasing. If you look at the datasheet you'll notice that it states erase cycles.
Erase operations are block based. So an entire block of data is erased at once. And in your case you can do this at least 10k times to each block.
Your idea can work, but any wear leveling algorithm needs to be block based, otherwise it will not provide additional life to the chip.

Also, in my experience, that number in the datasheet is fairly conservative in order to guarantee coverage under all temperature extremes. So at relatively modest temperatures (close to ambient) you may get many more cycles. In one chip that we had this issue with, it was specified at 50k cycles, but we routinely got close to 300k before issues arose.

And finally, as part of your algorithm, after you erase the block, do a check to make sure all bits were reset. If not, then erase again (up to two times). We found that this greatly extended the useful life of the flash, as the failure mode is not hard, but more of a soft curve.

If you want to avoid all the extra algorithm stuff, you can usually find an FRAM chip that is a drop in replacement for most EEPROMs. They do not have the same wearout mechanism and can be erased/written 1 Trillion times typical.

\$\endgroup\$
3
  • 4
    \$\begingroup\$ Note that FRAM has destructive reads, so reads count toward wearing it out just like writes do. \$\endgroup\$ Mar 10, 2021 at 6:14
  • \$\begingroup\$ @forest: Wikipedia does mention FRAM read/write endurance in terms of "cycles" (en.wikipedia.org/wiki/Ferroelectric_RAM). So unlike DRAM, one of the possible failure-modes does appear to be connected to how many times you write (with read implying a write because of destructive reads). You're right that "destructive reads" doesn't mean that reads wear the device out, but if writes do, then destructive reads mean that every read needs to be followed by a write. (Unless a controller somehow optimizes exchange-with-zero...) That's what Joseph was (correctly) saying. \$\endgroup\$ Mar 10, 2021 at 8:12
  • \$\begingroup\$ @PeterCordes Ah I see (just checked the MB85R4001A datasheet Wikipedia cites). I was under the mistaken impression that writes caused by reading took less power than "overwrite" writes. \$\endgroup\$
    – forest
    Mar 10, 2021 at 8:15
6
\$\begingroup\$

As Graham Nye pointed out in a comment, where are you going to store your write and read pointers?

I think most flash controllers (SSDs etc.) which implement wear leveling either use more durable non-volatile memory for the pointers or keep them in volatile memory and only write them to flash before they run out of power.

In a data logger I helped develop we made use of the fact that our EEPROM erased to all 1s and our data was guaranteed to never be all 1. So we just had to search the whole EEPROM on startup to find our data and initialize our pointers ;)

\$\endgroup\$
4
\$\begingroup\$

EEPROMs usually can't write a single location (although it may be appear that way to the user), they read, erase and write a block (16 locations or so), so unless your rotating locations are far enough apart, your idea won't help. The multiple locations in a block will wear out together.

Page writes are described in the datasheet, but blocks (smaller than pages) are usually not. I found out about them during an in-depth analysis of EEPROM failure mechanisms. Only the manufacture knows how their chips work internally.

\$\endgroup\$
2
  • \$\begingroup\$ Got it - We're gonna confirm with the design engineers how they perform writes. That team is in Asia so it'll be overnight before I can get a reply at best. I needed a sanity-check on the idea this afternoon. Much appreciated! \$\endgroup\$
    – Kyle B
    Mar 9, 2021 at 19:07
  • 3
    \$\begingroup\$ A common solution for EEPROM is to have more than one banks and alternate between the entire banks. This technique also allows you to recover from corruption on write if you store a checksum and record a "save counter". In the case of corruption, you just go to the previous bank. This is very common for writing to firmware and video game save files on handheld cartridges. A nice side-effect is that it reduces wear considerably. \$\endgroup\$
    – forest
    Mar 10, 2021 at 8:07
3
\$\begingroup\$

What you propose is a technique called wear leveling. That is, write to different locations over time to spread the activity across more cells.

A difficulty with EEPROMs is that they're block oriented (and fairly large blocks at that.) So the 'wear' of a write affects the entire block of cells. If you have to write stuff more than a few times, it's not such an appropriate technology for you.

Can you consider NOR flash instead? This has better write durability than EEPROM.

\$\endgroup\$
2
\$\begingroup\$

Fatigue only affects the cells that have accumulated too many write cycles but be sure you read the device manufacturer's datasheet to understand what they mean by cycles. Not all behave the same say.

But the general method of what you're suggesting is commonly used and is effective.

I'll also note that there are many EEPROMs on the market today that offer more than 10K cycles. You might want to shop around if that's an option.

\$\endgroup\$
2
  • \$\begingroup\$ Thx for the quick reply! Can't shop-around, it's an ASIC. It is what it is.... Datasheet isn't super helpful either. We're kinda in a niche market, we take what is available to us. \$\endgroup\$
    – Kyle B
    Mar 9, 2021 at 19:02
  • 3
    \$\begingroup\$ Keep in mind that in nearly all cases, wear only occurs when a cell changes state. So you can minimize wear by using data encoding that reduces state changes in the EEPROM cells with attention being paid to those that are not "in use" yet. You want to avoid wearing your reserve cells. \$\endgroup\$
    – jwh20
    Mar 9, 2021 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.