Lifetime of flash memory?

Here is an analog for cars:

If you drive your car like a normal person, and change your oil correctly, you never have to worry about your piston rings going bad. How often do you think about your piston rings when you start your car? Probably not often.

If you drive your car in a professional race, I gaurantee you are always thinking about your piston rings.

In this example, changing your oil correctly is making sure you aren’t executing any code that is running in a loop erasing or writing memory unintentionally and someone who is developing code non stop is like a race car driver.

For the average user, it is not important to worry about this stuff, because as long as you are doing normal things with it, you won’t ever run into a problem. For the “power user” or someone who is trying to push the device to it’s limits or doing development in ways that is non standard, it is important to know that flash writes are a consumable resource in practice not only in theory.

4 Likes

guarantee.

Nice example.

Personally, I don’t really care.
Now this can probably tell you why:

I use my laptop every day. For the past 6 months this computer is using the same SSD. (with everything on it)
My Samsung SSD (256GB) is designed to have 150TB (written) before dying.
I just checked, and the Magician Software says:


This laptop is already 7 years old. Even if it is completely new it means that the drive will probably fail after 150(TB) / 0.5(TB)*6(month)*1(year)/12(months)= 150 years.
For Arduboy, think this:
Say you save your game 10 times everyday. (reasonable)
You have 10,000 writes.
That is 10,000(writes)*1(day)/10(writes)*1(year)/365(days) = 2.73(years)
Also, I will GUARANTEE you that you won’t be playing it everyday.
Say you play 5 days out of 7. No. 4 days out of 7.
2.73 years / (4(days) / 7 (days)) = 4.79(years)
NOT to mention that you also have the simulator(both online and offline), it easily lasts 4 years.
I doubt you don’t change your laptop by then. Or if you can still find it by then.


Thinking twice, I don’t see why must it be EEPROM. It can be RAM, you know.
The SRAM. Or the Static Random Access Memory.
Because the rechargeable battery is still inside. Since SRAM don’t use a lot of electricity, this will probably last long. AND Static Random Access Memory is LIGHTNING fast (CPU cache)
It’s expensive, however.

1 Like

The game states (highscores, etc) for games that store it are saved to EEPROM (100,000 writes per individual bytes), not Flash (10,000 erases per block on AVR).

Flash contains program and read-only data, it is only rewriteable by the bootloader (when you put a different game in).

For practical normal and even development-testing use the OLED screen and buttons will wear out faster than the Flash. Not even mentioning the LiPo battery or the USB port itself.
And no, they’re not flimsy. The flash will simply outlive them if you really spend that many hours playing with the Arduboy.

Flash wear is an non-issue.

2 Likes

So it will be 40 years.
lol.
I’m just using these as examples. LiPo (supposedly Li-ion battery) would probably fail.
I reason the screen should be pretty long-lived. Buttons are also plated and should survive.


On a computer, though, most of the time the motherboard will out-live the solid state drives. The CPU will mostly outlive others.
Let’s just not talk about that, shall we?


The rated minimum display life depends on the brightness that the pixels are run at.

From the datasheet:

I don’t know what default brightness the Arduboy runs the display at.

2 Likes

The problem with OLED screens is they are organic and their life also greatly depends on how well they are sealed from oxygen reacting with the active substrate. For this reason they have a shelf life even when not used. This is more an issue with early OLED screens where the manufacturing process wasn’t great. I have several mp3 players that use these early screens and now they don’t light up at all anymore. I think modern screens are much better in that regard but they still technically are susceptible to decomposing very slowly with age.

2 Likes

When I first made the Arduboy I was really worried about this, I left several Arduboys plugged in and running for about 3 or 4 months continuously and saw no adverse effects. I’ve only seen one or two screen problems and it seems to be some failure in the boost converter circuit causes the screen to go dim and I think that has more to do with shock loading or vibration than any electrical problem.

Yeah, I’m not saying the screen has issues. I’m saying in normal use the screen will be considered expired (50% loss in brightness) before the flash. They’ll still be very playable at 50% brightness.

To clarify my feeling on this, @bateske I’m tired of the worries over flash rewrites too. I get it for Uzebox since that console is overclocked (Lot more worries over flash in that community), throwing out the window the guaranteed numbers before the flash fails to keep up with the CPU, but it makes little sense to worry over the Arduboy.

I’m gonna put numbers in perspective here (I’m using the specs sheets from similar parts).

1st, the price:
It’s $49 USD, that’s under $0.005 per (manufacturer guaranteed) flash rewrites. Half a cent.

Half.

A.

Cent.

Next, OLED:

Storage is best case if not in use (not exposed to UV, sunlight, and other light)

10,000 erases vs 20,000 hours best case storage for OLED, which means the flash need to be erased every 2 hours on average to possibly die (worst case) before the OLED is considered expired/faded (worst case too) while in storage, unused. With usage & exposure it’s going to wear faster than this baseline.

Dome Buttons:

Dome buttons are rated “1M cycles”, some “5M cycles”, that’s 100 to 500 clicks between flash rewrite. And even the high figure is very easily reached during normal gameplay.

USB Connector:

10,000 insertions of the USB cable.

That means that if you insert the cable more often (eg: to charge) than you change games the connector will wear out before the flash.

Battery:

Note: The Arduboy is very gentle on the battery so typical numbers are pessimistic, but I’m using what numbers I can find.

Okay, so at least the battery might very well outlive the flash. I take that one back.

:rofl:

Not that any of this is going to stop people worrying about it.

IT’S HALF A CENT PER REWRITE. Y’ALL SPEND WAY MORE ON SNACKS & OTHER ENTERTAINMENT.

I guess it’s cool people love it so much they worry about its longevity.

2 Likes
1 Like

I’m not very worried about flash wearing out. What does worry me is somebody writing a sketch that wears out EEPROM.

A person that is unaware of the limited write lifetime might decide that they want to save the state of the game so one can power down and continue where they left off after power up, without having to manually save the state. They might decide to save everything on each frame or each time a character moves.

If you’re writing to EEPROM 30 times a second, it won’t last long with a lifetime of 100000 writes.

A developer could even unintentionally and unknowingly end up continually rapidly writing to EEPROM, for example by doing something like:
if (x = y) saveState();
by mistake, instead of:
if (x == y) saveState();

There’s also the slight possibility of malicious intent.

This is why I won’t load anything that doesn’t provide source code that I can examine and compile myself.

3 Likes

Curious, because I’m looking at EEPROM usage right now, how many games have you found have done this? Or even use EEPROM to save anything at all?

Any chance you’ve cataloged any of the results? I’ve considered writing something that goes through hex files and searches for eeprom write commands actually.

None so far but it only takes one.

Could also modify the emulator to notify of EEPROM writes.

Only the most simple EEPROM code bug would be caught by a casual code review. A condition variable triggering the save function could get trashed from anywhere in the code, even by a marginal stack overflow.

To be sure someone would have to look at the entire assembly output from the compiler to know exactly how much stack space each functions consumes and then not only trace the entire code flow but also account for re-entrant interrupts.

1 Like

I remember once there was someone who wrote a program that read from EEPROM constantly,
which isn’t quite as bad, but I think there’s still a read limit.

At any rate I think we helped them change it to not do that.

  • Dark & Under
  • Turtle Bridge
  • Lode Runner
  • Minesweeper
  • 1944
  • Fire Panic
  • Juno First
  • Circuit Dude

Et cetera, et cetera, ad nauseum

This was going to be my next suggestion.

And I was also going to say about the possibility of EEPROM being written to in a branch that’s never taken that the compiler couldn’t optimise out for various reasons.

I wasn’t going to mention the stack though, so that’s something.

Though if the stack overflows typically the Arduboy just resets.
I think stack grown typically only clobbers heap space anyway,
but I’ve never really checked.

I’m trying to think of how to write a destructive memory tester app. For EEPROM I suppose it is pretty easy, I guess for the flash memory you’ll need a host. Maybe I should hook up a few Arduino Micros to a RaspberryPi running a flashing script in python to see how long it goes.

For science.

Anyone want to help out with the scripting? :slight_smile:

Does the atmega32u4 not allow flash memory writes outside the bootloader? I’m more familiar with PICs and it’s pretty easy to write to flash (albiet you are obviously limited to block not byte addressable). Should be easy enough to whip up something that writes a known sequence to the smallest writable block at a fixed location and reads it back to verify, then erase/rinse/lather/repeat.

Hmm, yeah I suppose you could write an application within the bootloader that does the destructive testing so you wouldn’t need the host.

It would be a lot faster too since it wouldn’t have all of that bootloader protocol overhead.

And just trash the last chunk of an ATmega32u4 just before the bootloader so it’ll still work with smaller programs :smiley:

I’m waiting on an SPI SSD1306 from China (I only got I2C ones and don’t feel like converting them :stuck_out_tongue: ) so I can experiment with a clone rather than open up the nice Arduboy.

I’m up for writing this once I get the part. I got a few $5 Pro Micro clones I don’t mind destroying the last flash chunk since they’re going into my homemade DDR dance pads and I don’t need the full space for just an HID joystick device.

It’ll be interesting to compare longevity of a clone board (might be a QA rejected chip) vs an (assumed) legit part. I’ve had to order a genuine Mega2560 board because the two $12 clones I have won’t flash reliably past the first ~32KB. I suspect the MCUs are from a rejected pile.

1 Like

No, there’s no limit on reading EEPROM.

Reads will fail eventually due to the the way EEPROM retains data but that’s a time limit not affected by the number of reads.

The specification for the ATmega32U4 that the Arduboy uses is:

Data retention: 20 years at 85°C / 100 years at 25°C

2 Likes

I have no idea where I got that idea from then.
I must have misread something or got it mixed up with something else.