Lifetime of flash memory?

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.


So it will be 40 years.
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.


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.


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.




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.


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.


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


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

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.


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


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