How many times can you write to the Arduino EEPROM without killing it?

These are the results from my month long experiment.
My Code:
github.com/mud...
Pick up a 3 pack of these boards using my Amazon link
Buy US - amzn.to/3iO5X1G
Buy CA - amzn.to/3K3YeZL
The book in the video:
amzn.to/378pEiy
Or, if you're interested in Arduino, pick up one of my 5 best rated starter kits.
2022 Arduino Starter Kit of the Year
ELEGOO Mega R3 Project The Most Complete Ultimate Starter Kit
Buy US - amzn.to/3kvYu5Q (Mega)
Buy US - amzn.to/33wdMEY (Uno)
Buy CA - amzn.to/3pzL6Sj (Mega)
Buy CA - amzn.to/3IXwrd8 (Uno)
Video Review - • Elegoo Ultimate Starte...
2022 Best Enthusiast Arduino Starter Kit
Dr. Duino Explorer Edition
Buy - www.DrDuino.co... (Non affiliate)
Video Review - • Dr. Duino - Arduino st...
2022 Best Budget Arduino Starter Kit
Grove Beginner Kit for Arduino by Seeed
Buy US - amzn.to/33ynCnd
Buy CA - amzn.to/37HUPO7
Video Review - • The Best Arduino Start...
2022 Best Arduino Starter Kit for Kids
Keyestudio STEM Starter Kit (Arduino)
Buy US - amzn.to/3ivt8hS (Arduino)
Buy US - amzn.to/3se0V4I (Microbit)
Buy CA - amzn.to/3sxdto7 (Microbit)
Video Unboxing - • Mailbag 26 (Filmed from the road)
2022 Best Arduino Starter Kit for Students
Freenove ‎FNK0059 Projects Kit
Buy US - amzn.to/3od4rbP
Buy CA - amzn.to/33wnxmA
Video Review - • Freenove Arduino Proje...
Thanks to these creators for the free animations
Calendar Animation: • Free Stock Videos - ca...
Confetti Animation: • 4K Green Screen Confet...

[@CallousCoder]

Seriously I’m watching this whilst on the loo!

[@AnotherMaker]

This could be my favorite comment ever.

[@stevealdrich2472]

What an amazing coincidence!

[@zombieregime]

When you're reading datasheets while on the throne, thats called preemptive multitasking 😉

[@CallousCoder]

@@zombieregime hahaha 😜 brilliant

[@zombieregime]

@@stillness0072 Well.... ideally not. But a dropped semi-colon can lead to a hung up return.....😁

[@nccyr1]

Thank you!!! I won't feel as bad (and concerned about killing the EEPROM) now when I write a new sketch because I had a stupid bug in my code ;)

[@AnotherMaker]

Yeah. For years, I've heard a ton of different numbers tossed around. It was kind of nice to put at least a guestimate in the real world.

[@_droid]

This didn't test the program area flash memory. This just tested the EEPROM flash which is a separate hardware area and even has different life specifications in the datasheet.

[@nccyr1]

@@_droid Oh! Thank you for the clarification.

[@WacKEDmaN]

in this case...EEPROM != Flash... EEPROM on arduinos is used to store variables you want to keep over reboots...Flash is where the "sketch" is stored, and should not be confused with EEPROM or any other memory..

[@DrakeOola]

Flash memory and EEPROM are different, you upload code to flash memory but it's actually degrades roughly 10 time faster, instead of 100k cycles it's only reliable for 10k. That may not seem like much but think of it like this, you'd have to upload code to it 27 times a day every day for an entire year to reach that limit or a more realistic number, using it 5 times a day every day it would last over 5 and a half years... Doubt you'll ever get close to that or keep using the same microchip long enough but if you actually manage to do so they're still only $3 or so. Of course, the 10,000 is like a "best buy" date for canned food, not an exact measurement. Just like you've seen with the EEPROM figure, you're likely to get 20x that amount before running into any issues. The first 10k is just guaranteed to work, you could easily reach a million cycles before noticing any issues...

[@anispinner]

Awesome test! One thing to consider that the devices were constantly powered. But the cells usually go instable when they are disconnected from a power source for too long so in case we were doing 100k cycles and let it sit for a couple of days before doing another 100k cycles results might differ.

[@AnotherMaker]

Interesting. I hadn't considered that. And obviously I only tested 2 boards, so I would expect results to vary wildly. Thanks for sharing.

[@elsekling2552]

​@@AnotherMaker I am not that familiar with EEPROM internas. But for NorFlahes I know that the life time depends also a lot on the writing profile you use. e.g. a memory may work just fine when you test 100k cycles like this. But it will lose the ability to hold data for long time, e.g. randomly data gets lost after 2 weeks... or maybe even just minutes / seconds. Depending on the degree of degradation. Also, average write and erase times will increase. This is also one reason why in the datasheets you can usually find a huge gap between "typical write time" and "maximum write time". Gates will be switching slower. Of course it also depends on other factors like temperature, power, age, etc... It makes huge differences if you just write write write non stop... or write, pause, write, pause. Second scenario will increase the life time and number of max write cycles drastically. In short... those things are very complex and its very difficult to pin point certain numbers even when testing with many many devices many times. Sometimes even some components have already a lot worse performance and lowered lifetime directly out of the factory.

[@brettfo]

@@elsekling2552 i imagine you also need to consider operating conditions like temperature.

[@dr_jaymz]

When the EEPROM is knackered it may verify ok initially but its retention can become unreliable. That's why the published figures after so conservative. It should retain state for 20 to 40 years.

[@ahmetmutlu348]

Write time wont increase... unless you implement data verification function to wait until its werified ro be there. Standard eeproms are bare hardware and has no os that does that waiting loop for you .. im giessing arduino doesnt hawe that built in.

[@ernstlemm9379]

I did a similar test. It apears that eeproms tend to 'remember' the data not as long as specified, usually 10..20 years minimum. The test is checking the eeprom very short after the write. It will detect malfunction much too late.

[@AnotherMaker]

That's what I'm hearing. It would be kind of funny to plug the thing in once a year and check it. I'm guessing in 5 years mini USB cables will be nearly impossible to find, so I better hang on to it.

[@Terandium]

@@AnotherMaker nah u can always order the cables online, however getting them from your local store will probably be difficult haha

[@MrJozza65]

It always concerned me that Eeprom writes were limited. However, I figure that if I saved my WLED settings 5 times I day, I should get about 1095 years use from it. That'll do 🙂

[@RGPinger]

Ye, it is funny how people are afraid to use EEPROM because they think, it will die soon. But they upload sketch with edit of single row to Arduino flash that can based on datasheet handle 10 000 times overwrite...

[@AnotherMaker]

haha. Yeah. I'm also one of those people who hates seeing my cell battery get low, so I feel the same way about my writes.

[@StereoBucket]

@@RGPinger Same deal with SSDs, people wildly underestimate how much you can use them. Though still probably shouldn't cheap out on them. They may not be hard drives, but a bad one will fail you even faster. Looking at you Kingston A400. No coincidence that the only two people I know who've had them no longer have them.

[@joonasfi]

That'll do pig, that'll do

[@kuebbisch]

@@RGPinger And you have to remember that the datasheet write cycles are guaranteed values, so Atmel/Microchip will have ran similar tests and added like a 10:1 safety margin, so I wasn't surprised by the million writes before failure. Another chip produced on a monday may have failed after "just" 1/4 million writes, but would have been perfectly in spec. And in you use case if you don't need the whole capacity of the EEPROM for your settings, you can also implement some sort of wear leveling, like having a counter in which points at your configuration byte and get tons more write cycles before your product fails.

[@codebeat4192]

Nice experiment. You must write 0xFF to flip all bits (cells) of a byte. Also, you must be sure the code or ATMega internally doesn't take smart actions or use a buffer to write to the cells. Better write the code in assembly to write to the cells directly and not by using a library.

[@AnotherMaker]

You're absolutely right on this. I was using the common tools because I think that's how most people would use it and I know very little assembly, but that would be an interesting experiment.

[@magoolew5131]

And here I am. I don't have a clue as to what you just said.

[@crides0]

@@AnotherMaker Don't think it'll actually make a difference. Since one can only access the EEPROM through a single byte anyway, buffering wouldn't make a difference (and would be unnecessary). Could also check what the EEPROM "library" does

[@codebeat4192]

@@magoolew5131 Haha

[@waldolemmer]

C++ doesn't make optimizations when writing to the EEPROM since all registers are declared volatile

[@yassinechih7620]

This it's what's KZbin should be used for. RESPECT 🙏

[@AnotherMaker]

Thank you kind viewer!

[@E231986]

This is a really good video! I wish it was longer but I don't think it needed to be. It answered the question as short as possible while still being comprehensive. I want to see more videos like this!

[@AnotherMaker]

Thank you. I actually have a few more creative ones coming up. I'm trying a little harder. :)

[@E231986]

@@AnotherMaker I'm glad you replied! I feel special. Keep it up man! This is the kind of fun content the world needs!

[@robertmonroe9728]

You should write 0x55 and 0xAA for testing the memory

[@AnotherMaker]

You're absolutely right.

[@dannihijacked2508]

can you explain why 0x55 and 0xAA exactly?

[@Kurkkulimu]

@@dannihijacked2508 0x55 is 0b0101 0101 and 0xAA is 0b1010 1010 so it will swap all the bits to get maximum amount of wear to the EEPROM

[@Daniel-ij3ks]

@@Kurkkulimu But he's writing all 0s or 1s on each cycle, would it really make difference?

[@QFSW1024]

@@Daniel-ij3ks he isn't, he's writing 0b0000_0000 then 0b0000_0001. Using 0x00 and 0xFF would also work to maximise the bits changing

[@XanCraft21]

Thank you for this short test. I knew the EEPROM chips would never write again after you go past the limit. I always thought they would still have infinite times for reading the values, but I didn’t think it would stop working all together let alone fry the processor at the same time.

[@AnotherMaker]

It actually didn't stop writing on its own. It just didn't read back the value it was expecting, so the test stopped itself. But that's kind of worse because it wrote a 1 thinking it was a 1 and got back a 0....so without that test, you could be storing bad data and not know it.

[@XanCraft21]

So you programmed it to stop if something is wrong? So the processor isn’t fried and still works fine. I wonder if everything else will still work normally without the EEPROM? I think it should you just can’t save data or anything. I do wonder if the unused parts of the EEPROM in your test will still work for at least a short time after the first few bytes have been used up.

[@C40V15]

A well done scientific process: hypothesis, experiment, conclusion. In less than 3'. Bravo!

[@AnotherMaker]

Thank you!

[@skellious]

Good to know this isn't something I have to worry about in regular use.

[@AnotherMaker]

Yeah. I think you're pretty safe, and if you do a read before writing to make sure the data has actually changed, you could probably extend the life a lot longer.

[@Firefox991gaming]

You earned my subscription. Im interested to see what tests and videos you release in the future.

[@AnotherMaker]

Thanks. I'm working on some fun stuff. My channel is definitely a little random because a lot of different things interest me but I have some fun videos along these lines coming up.

[@stevemorse5052]

Congratulations AnotherMaker, a BIG thumbs up. This is the first KZbin video I have ever watched were the author (you) has responded to every comment. Thank you.

[@AnotherMaker]

haha thanks! There was a gap about a year ago where my comments got hidden from me, but other than that, I pretty much respond to every comment on the channel!

[@joelcordier6762]

Cool idea. Nice results. I also see you're an expert in low temp soldering 😎

[@AnotherMaker]

My hands are just really tough :) And thanks for watching!

[@ortega_computacion]

I have been thinking about this since 1993, never got to do it because a fatal case of procrastination, haha, loving you.

[@petittoto7433]

Bah, procrastination can wait...

[@AnotherMaker]

haha. It's been on my list for so long too. Not 1993, but a long time. Glad I was able to save your time and that procrastination paid off :)

[@AnotherMaker]

haha

[@prototypecrysis]

I've actually wondered about this for years, but never thought to sacrifice a cheap board to test it out! Cool vid, thanks for sharing!

[@AnotherMaker]

Thanks for watching. I've been thinking about it for years too.

[@epiendless1128]

Nice idea to check this. A while back I checked out Microchip's app note for their EEPROM chips. Turns out: 1. Quoted life was at worst case temperature and voltage. With nominal voltage and room temperature, life was longer. 2. Failure rate is a S curve. Only a handful fail at the rated lifetime. Most chips last longer but then all start to fail together. A handful keep hanging on. 3. On the chip in question, you could burst-write several bytes, and that only counted as one write.

[@AnotherMaker]

All good points. Yeah. This was an intentional torture hoping that things like your comment could be gleaned out and we could learn how to be smarter about it.

[@OutlawJackC]

Doesn't writing to solid state wear out some gate things, meaning it starts to leak elevtrons over time resulting in the stored value changing So while it may be able to be written to a million times and hold the data long enough for a read test a couple milliseconds later, would it be able to hold that data for a month without anything becoming corrupt?

[@AnotherMaker]

I think you're right. I'm definitely doing that test.

[@zama1500]

Another thing to remember data loss can occur under high tempatures and if left unpowered

[@MorRobots]

I would change the baud rate on your sketch, it will speed up the test. Also the 1Mill stat sounds correct given you hit 2.5 mill in your test, it tracks with typical probability density and how you would rate the reliability. If you were building a high reliability solution, you would not want to push it past 100k since that puts you well into a couple of 9's on reliability.

[@gurgelplus]

If I have seen it correctly then he always sends the count over uart…this is slowing down the process significantly. If he only writes the counter every 10 or more times the result will not be much changed but time for the test will be faster.

[@AnotherMaker]

Yep. Absolutely. I'd be interested in seeing how much faster it could be written.

[@AnotherMaker]

Absolutely. I think 100k is a reasonable safe bet and with wear leveling and not writing 33x a second, that could be 10-50 years.

[@MorRobots]

@@AnotherMaker is this a challenge!? Because I've got a nano that could probably be sacrificed to the destructive testing gods.... standby...

[@brado426789]

Thank you... That was super interesting and relevant to a project I'm working on right now.

[@AnotherMaker]

Awesome. Glad to hear it. Thanks so much for watching.

[@GnuReligion]

Epic way to burn a board out! Have always wondered about this. Odd that the thing is bricked, due to a component failure. Do you get any fuse readings with avrdude? Kind of makes me want to run a HVPP on the MCU to see if can be unbricked. I think there is a limit to how many times you can flash a board too ... a far smaller number. Surely have flashed a couple of mine hundreds of times without negative consequences.

[@AnotherMaker]

The one board bricked. The other board is operational, it just can't write to the eeprom. They may require an autopsy. And yeah, regarding flashing. I've flashed some a ridiculous number of times.

[@Chris-io2cs]

@@AnotherMaker is the entire eeprom dead or if you write to the bits that didn't fail do they still work?

[@kuebbisch]

I don't think it is odd to brick the whole chip. Most (every?) EEPROM is organised in pages, a unit more than a byte and surely more than just the 2 bits in the example. Physically the EEPROM needs to erase a whole page and rewrite the whole page with just the changed bits. If the first page of EEPROM held the configuration (like oscillator source, boot area flags etc.) and was rewritten while changing the first 2 bits of "user" EEPROM, there may be corruption to the vital registers read on boot-up and subsequent no-boot.

[@GnuReligion]

@@kuebbisch You are probably right. I figured they put the fuse settings on a separate block from user EEPROM though. (shrug)

[@someguy4915]

@@kuebbisch Interesting background, with that, considering that he actually wrote two Bytes with each cycle (16 bit int), is the Arduino compiler smart enough to combine those into a single page write or does this mean that he actually did twice the write cycles?

[@MichaelOfRohan]

This was a perfect video. Nice work.

[@AnotherMaker]

Thank you very much!

[@baldbadger7644]

if you delete all your Serial print code. you can read/write it much more quickly as the serial operation is taking the most of the arduino run time. It you just want to make sure it's making progress you can just print every 1000 R/W instead

[@AnotherMaker]

That's definitely happening in my next test. I'm going to see how much faster it makes it in reality. Thanks for the tip.

[@andyniemic4597]

First - A lot of EEPROM have built-in features like wear-leveling and bank writes. For wear-leveling, the EEPROM will spread the write out over the whole device. This is why, when you wrote a small amount over and over, the device die once it failed as the whole EEPROM has been worn down. For bank write when writing to an EEPROM, it normally write in a bank (group) of addresses at a time. For most SSD, the bank size is 4K Bytes. So if the bank size is 512 bytes (This is common for EEPROM that using a FLASH that is 1MB or bigger) than each time to write two bytes, it will erase 512 bytes modify 2 bytes and write 512 bytes back to the EEPROM.

[@AnotherMaker]

Absolutely. This didn't have any built in wear leveling to my understanding.

[@peerappel2012]

Interesting! Also weird that the one got bricked after it failed. Does it happen to draw exceptionally high power?

[@AnotherMaker]

I'm not sure yet, but I will definitely check. Thanks for giving me something to look out for. What would that mean if it did?

[@peerappel2012]

@@AnotherMaker I don't know just wondering. Its simply weird to me that just writing to the EEPROM (an absurd amount of times :-)) totally bricks the whole microcontroller. I am just speculating here, but maybe if the EEPROM fails it can somehow create an internal short circuit in the EEPROM, therefore also dropping the supply voltage of the arduino?

[@bigbani1334]

Please, do the same with FLASH memory!

[@AnotherMaker]

I love it. I'll do it!

[@MrSmeeds]

If the device is considered to fail upon a single bit of memory failing, then I think you need to write to all bits of memory in each round of testing to find the soonest possible failure. Writing to only the first few bits of memory will give a very optimistic underestimate of the lifespan of the device. By analogy, consider buying lottery tickets. If you just buy one ticket (I.e. check just one memory cell) per round, you'll have to wait a very long time to win. If you buy millions of tickets per round, you might expect to see a winning ticket (I.e. a failed memory cell) much sooner.

[@AnotherMaker]

Yeah. That is why I did 2 vastly different write amounts. Btw, the first test did write all the bits in the eeprom and then some. So I did do a complete write.

[@billglass5160]

You need to do wear-leveling. Write/read bytes to address+1 (in circular mode) each time. Spec. minimum writes before failure is 100K. With a 1kx8 EEPROM, you can write/read a byte 100M times before failure.

[@AnotherMaker]

I do agree. I'm going to cover wear leveling. I intentionally fatigued one area of the chip because I was trying to test it per bit in case you are filling the whole EEPROM.

[@billglass5160]

@@AnotherMaker I wrote a personal library to manage the circular addressing mode if you're interested. Let me know.

[@bowserko123]

@AnotherMaker so I can give you a bit more information, the write times for a traditional eeprom memory cell is usually a garenteed a minimum number of writes per cell. That num can go up or down for unknown reasons. I have been digging into this as I just got hired recently in a team that specializes in serial eeprom. From comparing a number of companies, each one has a different amount of reliability but for older tech microchip is the best. The eeproms there will usually last at least 1 million write cycles , but testing individual cells of memory, that can vary, I tested one bit and got 80mil+ writes off of it but the arrays of memory traditionally you will see errors after 1 million cycles and will exponentially get worse, that usually out performs most of the market. Atmel parts are also microchip parts too, you can find them on alot of arduinos.

[@AnotherMaker]

Thanks for the extra info. And obviously I could do wear leveling to extend the life

[@BlondieSL]

@@AnotherMakerI personally haven't used EEPROMWearLevel. Is this an automatic thing in a library where it will set the pointers as it moves things around, but the sketch only needs to use the original coded locations? If so, how does one implement this?

[@hamzahokasheh6145]

What book were you reading?

[@wizrom3046]

It is very heat dependent. You could re-run the test at elevated temperatures.

[@AnotherMaker]

I've been hearing that. I can put one in the air fryer :)

[@fitybux4664]

@@AnotherMaker if you ran two of them at two different elevation extremes (sea level/0ft and 10,361ft Alma, CO for instance) and controlled for temperature and humidity, the one at higher elevation should fail sooner. (Due to cosmic radiation.)

[@iDontProgramInCpp]

2:25 How are you holding the iron from the hot metallic part?

[@AnotherMaker]

I have tough hands.

[@igorordecha]

256 ints * 4B = 1kB so you wrote over the whole eeprom. What if you write only to the first half of the eeprom(512B = 128 ints) until you kill it and then try using the second half? Would it work or is the entire chip dead

[@AnotherMaker]

You're absolutely right. I will be trying. I'm going to figure out what is still useable on these boards. The second one still has plenty of untouched EEPROM

[@jasonelmore2900]

@@AnotherMaker I have used the first bit of memory to hold the offset to the data to be written often. When a failed write is detected, I change the offset to the data and continue writing to the new section.

[@Julenuri]

So interesting and getting the point fast.

[@AnotherMaker]

Thanks. I try to keep it straightforward. There's a trend where every video has to be 30 mins. I don't have that kind of time. Although these short videos take twice as long to make.

[@EKUL34]

So if I understand this correctly because your second run wrote to such a smaller amount of memory statistics say it will last more writes as less has to go right. As you need 256/256i to pass the first test but 2/2 to pass the 2nd test. The larger the memory the more likely it is that one part of it will fail

[@AnotherMaker]

Right. And it only took a single bit to fail for the whole thing. Spreading the test out over the whole memory space would have caused it to last way longer.

[@m4hi2]

The last quote involving "For Science" completed the video.

[@AnotherMaker]

Thank you. I'm glad that was appreciated

[@MrTerrymiff]

The EEPROM held on for 42,294 minutes. How long did you manage to hold onto the barrel of the soldering iron at 2:21 ?

[@windowsxseven]

He's built different. You wouldn't get it...

[@stevemorse5052]

About 100 ms. I have tested this hypnosis more than once. I used words not normally looked up in a dictionary in all cases.

[@MrTerrymiff]

@@stevemorse5052 Do you mean 'I have tested this hypothesis...'?

[@stevemorse5052]

@@MrTerrymiff Err, yes. And I thought I had corrected it!. Thanks! The last time I picked up an iron like that was about 2 years ago. That's how I know about the 100 ms.

[@AnotherMaker]

haha. I have pretty tough hands :) All my solder joints smell like bacon for some reason.

[@mt-qc2qh]

Sounds like a good exercise for the ESP as well

[@AnotherMaker]

It actually does. That's a big money experiment these days :)

[@MorgothCreator]

Atmega microcontrollers are more robust on a larger node and have a more broader upward tolerance, I tested an ATxmega128A1 and after 70K write/erase at @30-35gr celsius ( in datasheet 100K at 25gr celsius ) the EEPROM cells died, but died only for that page of 32 bytes, the rest of the pages were not touched.

[@AnotherMaker]

Ok. So interesting to know that the whole section died. Tanks for sharing!

[@AshleyFoxo]

wonderful video makes me feel less shit about my constant arduino reprogramming

[@AnotherMaker]

Thank you. And yeah, in "normal" situations it will last a lifetime.

[@ethzero]

Wow. I got this as a *Google Feed* recommend - great job!

[@AnotherMaker]

Thank you and thank you for watching!

[@Falcrist]

It's rated for at least X number of cycles because if you write to the whole EEPROM sector you should expect at least that much endurance before a failure. If you look at the data sheets for these chips, however, you'll find that the endurance is temperature sensitive, so at higher operating temps you get far fewer write/erase cycles.

[@AnotherMaker]

Absolutely. You're 100% correct. Thanks for sharing.

[@AiOinc1]

Yeah, all nonvolatile solid state memory has a finite life in this manner. This includes all kinds, bubble memory, flash memory, etc!

[@AnotherMaker]

Absolutely. I guess it's not THAT nonvolatile :)

[@DimensionDevices]

lmao, I love how you've shared the code like... "Yo, break your own Arduino here!" 😆

[@AnotherMaker]

haha "for science." In all seriousness, people have suggested a lot of different techniques, so they may want to alter it.

[@MaxintRD]

Interesting experiment. Good to know that your's far exceeded the specs. They were so much better... Unfortunately their remarkable survival skills were not good enough to survive your patience ;-) Will you replace the chip and try again? What would be interesting next is to see how this compares to similar chips, such as the ATmega168 (found on cheaper Nano's) or the LGT8F328P chip that is a remake of the ATmega328P...

[@AnotherMaker]

I'm going to do an autopsy for sure. I want to know exactly what died. I'll do some similar tests on other boards and see how they survive.

[@typeer]

I think that flipping every bit 1 to 0 and back might be easier on the hardware than like a deeply random mix of ones and zeroes. Random has more scenarios where Arduino is trying to hold 1 bit low while all other bit locations proximate on the memory wafer go high.

[@AnotherMaker]

I can see that. I'd have to kill a bunch more to fully exhaust this kind of testing, but your point definitely makes sense.

[@VndNvwYvvSvv]

Why is that harder on it when fewr bits will be changed? Shouldn't that roughly double the life since each bit has 50% chance to actually change on each write?

[@AllenKll]

So hot tip.... you're only writing it half as many times as you think. When you write a 1 to an EEPROM location, literally nothing happens as the erased state of an EEPROM is to produce a 1. Writes only physically change the device to a zero, and erases only physically change the device to a 1 - if it was not already in that state to begin with.

[@AnotherMaker]

I'm not an expert on that, but I don't believe that the hex/binary character 1 is the same as the integer 1...the integer takes 32 bits.

[@5Komma5]

Very interesting. Never tried it. Thanks

[@AnotherMaker]

Thanks for watching!

[@VndNvwYvvSvv]

You said the Arduino stopped working. Dead somehow or just those bits of the EEPROM? Couldn't you write some simple code to check writes and remap to a new block on error? Isn't this what SSDs do? It could check every write so that data is never lost.

[@AnotherMaker]

Yeah absolutely. I was intentionally trying to fatigue it. But there are a lot of weird leveling algorithms that you could write to extend the life considerably.

[@cloviscareca]

Why did the arduino died after killing its eeprom bytes? For the informations I got, arduino can run without the eeprom functional. Thank you

[@AnotherMaker]

Yes. That is my plan. I will report back.

[@lidarman2]

But how many licks does it take to get to the center of a tootsie pop?

[@AnotherMaker]

105 :)

[@GiBBO5700]

To me it seems like the charge pump is the limiting factor here. If you had one dead cell/sector instead it wouldn't effect the entire array.

[@AnotherMaker]

It could be. But I think one cell would affect it because the test is designed to fail if any one bit came back wrong.

[@H3wastooshort]

Can you still use the arduinos for stuff that does not require an EEPROM or do the go completely poof?

[@AnotherMaker]

I actually can. I'm going to do a full autopsy on them but the one actually works fine. It just can't write to the eeprom anymore.

[@davelordy]

Won't it depend on the brand ?

[@AnotherMaker]

Possibly. Although the brand refers more to the board and the other components. The chips are all built by Atmel. There's also a chance that some of the clones use seconds or lower quality chips.

[@cthoadmin7458]

Suspect the USB plug will fail before the EEPROM does. I killed a nano the other day just by touching one of the output port leads to ground.

[@AnotherMaker]

Sorry for your loss. Yeah. I want to figure out what exactly died on these.

[@RideGasGas]

Just curious, but did you try replacing the controller chip to restore the Nano to service?

[@AnotherMaker]

I'm going to do an autopsy on these. The eeprom is inside the atmega chip, so the only other thing that could be changed is the usb controller. I'll see what's borked.

[@electronron1]

i read somewhere that the EEPROM can be written to more times than program memory. I don't know if this is true but I try to be conservative on how often I upload changes to a sketch.

[@AnotherMaker]

I do want to test that. It would take a little longer though.

[@david-polak]

I see the good ol’ asbestos fingers soldering technique is still in use.

[@AnotherMaker]

I used to work in a restaurant :) I burned my hands enough it doesn't matter anymore lol.

[@nobodynoone2500]

Unless you do full writes, it's not the same. Wow, genius, you figured out the chance of one bit failing is way less tha 32kb failing.

[@AnotherMaker]

I'll take that as a compliment :-)

[@SimpleElectronics]

Did that soldering at the end smell like bacon? :)

[@AnotherMaker]

That's how I know I did it right :)

[@NormanNodDunbar]

That book looks interesting, looks like Apress too. Who is the author and what is the title please? If I remember correctly, the data sheet guarantees a minimum of 100,000 EEPROM writes. Cheers, Norm.

[@AnotherMaker]

Thanks for watching, Norm. This is the book. It's a little cheaper used. Either way it's excellent. amzn.to/378pEiy

[@NormanNodDunbar]

@@AnotherMaker much obliged, thanks. I like to keep a stock of good books.😉 Cheers, Norm.

[@samuelclemens6841]

The first thing that comes to mind is: 1 million writes per cell? Because there are many cells. So you could get, for example, 1 million writes per byte and then move on to the next byte

[@AnotherMaker]

Yeah my second test was a lot closer to a per cell test ... Although they are always written in blocks

[@BlondieSL]

So here's something. And yes, it's cause by a guy who was tired and didn't think about the consequences of using EEPROM.put instead of EEPROM.write sighhhh.... So a couple of years ago, I made what I call a Mini-sump-pump device. There's an area that gets water where it should not and using a full-sized sump pump is out of scope. So I designed an arm with a float on it, which turns a potentiometer. I use a NEXTION display to monitor everything as well as having a settings page where I can adjust trigger positions. i.e. what's the number when the float is up, indicating it's time to turn on the pump and what is the number when the float is down, indicating water has been pumped out. There are some other numbers too. BUT, not thinking this through very well LOL I had a variable that would count every time the pump was turned on. I'd pull the current count saved to EEPROM, increase it by 1 and resave it. EVERY TIME.... sigh... LOL I wanted to get an accurate number of how many cycles this thing went through so as to get an idea of how often the water raised up in the area. So, after running fine since Dec2021, I started to notice that the trigger numbers seemed to change or at least, the float's actual position numbers seemed to change.... so I checked the counter and it was at 29,597. Due to that number is why I was confirming what the max writes might be before failure. BUT, then I realized, using .put instead of .write is where the problem was. .write writes a byte, while .put writes as many bytes as needed!!! BOOM! So needless to say, I'm now reworking the code to remove the counter as it really isn't needed and I'm going to change all .put to all .write. Lesson learned!

[@pawesomepal7827]

It would be interesting to see if writing random bit values each time actually has influence on the chips health.

[@AnotherMaker]

I'm definitely doing that in my next test.

[@EpicHardware]

finally, when I got my first and only ardoino in 2009 I was very afraid of existing this limit and I had limit my self not to use it. what a terrible thing I did

[@AnotherMaker]

Yeah. I felt exactly the same way.

[@ubuntukali2997]

Wow it's cool; would you suggest the book to read;

[@AnotherMaker]

Thank you. This is the book. It's not cheap, but it's very good. amzn.to/378pEiy

[@nielsdaemen]

But if you kill the EEPROM the rest of the chip should still work right? Since its separate from the program memory. And if you only kill certain parts of the EEPROM the rest should also still work.

[@AnotherMaker]

Yes. I believe the higher addresses of the EEPROM should still work and the board should work fine, although I still need to do an autopsy to find out what damage I really did. The goal here was to stress individual bits of the EEPROM. I'll definitely need to figure out how to test the rest of it.

[@pp9043pp]

why did your code took like a 1s to complete with a 1Mhz clock of the arduino?

[@AnotherMaker]

I was just alternating 1 and 0 to force it to write every bit every cycle

[@supercompooper]

I like you answer the question quickly

[@AnotherMaker]

Thank you! I like faster youtube videos, so I try to make mine that way.

[@fitybux4664]

1) EEPROM and Flash have different write cycle endurance on these chips. EEPROM is made for LOTS of reads/writes. Flash is not. You might get a few hundred thousand cycles if you're lucky. 2) You should still be able to read the EEPROM/Flash even after it can't be written to anymore.

[@AnotherMaker]

I could still read it. It was just not accepting any more writes correctly

[@Bunny99s]

Well, of course it would last way longer, as always. However the figures the manufacturer gave out are the ranges where it should be guaranteed to work properly. Things can easily change with temperature changes. Even when a bit error happens only rarely, depending on what you're doing, any error may not be acceptable. There's always a chance that you get errors even when you are still below the specified threshold. Though chances are very slim.

[@AnotherMaker]

Yep. Some people will get below the number. Probably a lot more will get above it because they are conservative. I'd like to see the differences with the temperature changes. I wonder if they'd be measurable.

[@Bunny99s]

@@AnotherMaker Sure, would be a great test :) Though reliable figures can only be gathered through many tests and take statistical average. Even though electronic circuits do not have any moving parts, they are still subject to wear and tear, just on the atomic level. So there's a lot uncertainty in there which could contribute to the life time / write cycle count. The manufacturing is just as precise as necessary and as bad / simple as possible :)

[@Ancyker]

I saw some people on forums and in Discord complaining about the 10,000 write-endurance flash on the Mega2560. If only they paid attention they'd know their expensive 1TB Samsung 980 Pro M.2 NVME SSD was only rated for 600 write cycles. 🤷‍♀😅 I don't think people really comprehend how many write cycles the 10,000 for the flash and 100,000 for the EEPROM truly are. Like, that's an asinine amount of writes. lol

[@mahboudz]

Good job! Thank you!

[@AnotherMaker]

Thank you and thanks for watching!

[@shinesanthosh]

I've always wanted to test this. Thanks mate ❤️🤣. Pls Do the same with esp8266 and esp32 too 😬

[@AnotherMaker]

I will probably sacrifice a few other boards in some testing.

[@mjyanimations1062]

Those boards use similar external spi flash chips so killing them might not be as bad as killing the eeprom on a mega328p.

[@forbiddenera]

Thanks for the research

[@AnotherMaker]

Thanks for watching!

[@InspektorDreyfus]

It should be worse in higher temperature. What is the temperature rating of the eeprom?

[@AnotherMaker]

I'm not sure the rating, but my office was 76f for most of the test.

[@tyramisiu]

However, you should do the tests at extreme temperatures and voltages.

[@AnotherMaker]

I'm totally down for torturing a few more boards. :)

[@E231986]

OOOOH I like this idea a LOT. Also humidities maybe?

[@montecri]

Great idea! Leave one battery powered on a fridge, another one on an oven.

[@istvanbarta]

I wonder if there is any option the read out the health of the EEPROM (like the SSD drives)?

[@AnotherMaker]

I don't think there is but I'm definitely going to do an autopsy and figure out what is good and bad on the boards.

[@3mwithjoao]

Awesome video. 😊 what book is that please?

[@AnotherMaker]

It was beginning C for Arduino and it's excellent. My favorite Arduino book. amzn.to/378pEiy

[@tubeDude48]

Where's there a link to the code?

[@AnotherMaker]

Thanks for remidning me! github.com/mudmin/AnotherMaker/tree/master/arduino-eeprom-torture

[@fdmillion]

The EEPROM for user data storage is a lot more resilient than the program flash memory. I think the program flash is only specified to around 10K writes. The difference is you normally only ever write to program flash when uploading new code. (You can write to program flash from user code - this is after all how the bootloader works - so in theory this test could be adapted to test the program flash too...)

[@AnotherMaker]

Yeah. I've been thinking through a good test for the program flash.

[@icebluscorpion]

That thing can still function, just replace the eeprom chip and it will be good to go up and running again. Solder joints can be reheated 4 or 5 times if you do it right which means you can replace the chip 4 to 5 times. Until the PCB or the pads say bye bye. And if you use pin heather socket for the Nano then you can replace a couple 1000 times the nano itself and for every nano you can do the same chip changing procedure so you project what ever it might be could survive the live spane of your entire life and of your descendants many times over so please don't just throw that Nano away. It has barely been produced. PS: I Subbed, up voted and broke your bell icon to see more of this Madness 😎👌

[@AnotherMaker]

I believe the EEPROM is just part of the ATMEGA 328. And thank you. More madness to come. I'm definitely doing autopsy to find out what these boards can and can't do. Thanks for taking the time to sub and comment!

[@icebluscorpion]

@@AnotherMaker yes it is indeed in the ATmega 328 integrated. Replacing the ATmega 328 chip is not big of a deal with the right technique and equipment. Nothing that can't be done with a bit of praxis and knowledge. I mean I started in my new job as a newbie as well and now replacing such chips on a daily basis is pretty satisfying.

[@Mizai]

can you test how many times to write to a sd card

[@AnotherMaker]

I am definitely doing an sd card next!

[@RamjetX]

Earned a sub from me... cheers for your sacrifice.

[@AnotherMaker]

Thank you so much. They died an honorable death.

[@byronwatkins2565]

I am surprised that the Arduino "doesn't work any more." Certainly, those 256 EEPROM locations are dead -- possibly all the EEPROM is dead -- but I would expect everything else to work fine. The 100,000 is the manufacturer guarantee... typically, only 1 in hundreds of thousands will have durability so short.

[@AnotherMaker]

I'm going to do a complete autopsy. I know one is still good for something. The other wouldn't connect to the pc any more, but I'll get a full report.

[@NicksStuff]

It stopped working entirely? Wow!

[@AnotherMaker]

The one did. I'm going to do an autopsy to figure out what died.

[@Dreamsarefragile]

Press F to pay respect

[@AnotherMaker]

Ahh. Thank you :)

[@Jonas_Aa]

So if eeprom is bad the Arduino will not work at all, even with a sketch that does not use the eeprom?

[@AnotherMaker]

The sketch actually still runs fine on the 2.9 million one. The 5.6 doesn't. I want to get to the bottom of that.

[@xtevesousa]

@@AnotherMaker Try reading/writing the configuration byte/memory. it's eeprom too.

[@ДаудМухамеджанов]

The thing is that amount of 100k or any given value from datasheet is guaranteed and measured:you have 99.8% probability that it would work for more than 100k cycles. But for example it can die just in a next cycle OR in couple of millions cycles. Then, there is another problem, you didn't made a check: how long it can store the data. Because when you are over the limit you can loose your data in couple of weeks, but those 20 years are guaranteed when you are in limits. Why it is limited? Basically, because mosfets are capacitors with semiconductors. Metal oxide that is used as an isolator to create famous mosfet structure is usually an oxide of the metal that is non-conductive and pretty nice isolator. But for memory cells they put one more gate at the top of the regular gate: sandwich like structure. So, because of this it changes I-V characteristics of transistor that can be used as memory. But the problem is the degradation of oxide layer because you are breaking down the gate capacitor with each cycle: material gets polarized and IMO it gets a shockwave and slowly looses density that decrease isolation properties that would make that thing unusable. Why we don't use material that has supercool isolation properties? Because that thing is already a very nice isolator, but in dimensions of micro and nanometers you can't take much. Then, there is a problem with capacity of oxide layer that depends of isolation constant of material: IMO you can end up with memory that needs a lot of power to use it fast. More Cox-more current is needed to charge it fast l and there is a problem of power design, emi and so on- things are becoming more complicated. So, it is always a trade off: I wouldn't be surprised that you can get memory that would be very stable and very reliable. But it would be slow and take a lot of power, comparing to the other configurations. But yes, when you write something in the memory-there is a current spike.

[@AnotherMaker]

Yep. you're absolutely right. And thanks for the awesome, detailed information. I've learned a lot from the great comments on this video...yours included.

[@Tsnafu]

Sip of coffee (it's 9am) for the two poor dead arduinos that gave their life for science

[@AnotherMaker]

Thank you for your condolences. They were great boards.

[@DoNotEatPoo]

Thanks. I invented a weather station a few years ago with fancy graphs. Being concerned about exactly this, I save values to eeprom once every 30mins. So I should be set at least for another few months before it explodes.

[@supercables251]

you mean centuries?

[@AnotherMaker]

Probably way more than a few months unless you started it in the 1700s.

[@sharp14x]

About 6 years if you assume the 100k writes.

[@GiannisKaralis]

49998 writes and checks, after write FF and then 00, pause and check the next day if all 00. this way you may examine the data retention too. i am not sure but if cells act somehow like a small capacitor where small leakage after degradation will not be obvious if you write and read immediately. if this is true the real degradation will show up i less cycles.

[@AnotherMaker]

Yep. You're absolutely right. Even if it survived a million writes, the retention would probably be weakened.

[@thanks600]

Pls try same test in flash memory, use same atmega328 nano which eeprom failed.

[@AnotherMaker]

I will try. Thank you for the suggestion.

[@haruki_nyan]

I had a board that had a 4MiB FLASH (custom SNES cartridge) that stopped writing correctly after only a dozen writes or so. Although, to be fair, the chip was rated for 3.3V, and the SNES outputs 5V, so I have no one to blame but myself.

[@AnotherMaker]

Yeah. That will do it. It's nice to know it could take some cycles at 5v though.

[@haruki_nyan]

@@AnotherMaker Actually, what's interesting is that I can still sometimes flash it if written to slowly in small block sizes. (Though it's hardly worth it when it needs to repeatedly re-flashed to debug a program on hardware.)

[@mr_gerber]

Why not just step down the voltage from 5 to 3.3 V? (and use level converters for logic)

[@haruki_nyan]

@@mr_gerber The S29GL032N FLASH has an absolute maximum voltage rating of +4.0V on VCC, and VCC+0.5V on most other pins. For a 32Mbit FLASH, that means I need to have level shifters on each of the 23 address, 8 data lines (which would need to be bi-directional for in-circuit programming), read, write, and chip enable, totaling at least 34 level shifters, with limited board space. The increased cost, complexity, and risk of failure would be too much for me, as I am a college student software programmer, not a professional electrical engineer.

[@mr_gerber]

@@haruki_nyan I think you can do it! Fair answer, though.

[@PanthereaLeonis]

This is telling me that I will accidentally step on mine *waaaay* before it breaks from wear and tear from writing to it.

[@AnotherMaker]

I think that's good to know. I always felt like if I stored a temperature there every minute or something that it would be dead in a week.

[@Jenny_Digital]

If you write to _more_ memory, does it seem to wear out faster? I suspect there could be some basic wear levelling going on.

[@AnotherMaker]

I think it's a bit of luck of the draw. It only took one bit to fail for the whole test to fail.

[@0LoneTech]

Don't expect wear leveling in a device with no error detection and very little memory. It's not an SD card with its own controller.

[@AnotherMaker]

@@0LoneTech Right. I meant DIY wear leveling where you increment the memory location that you are reading and writing.

[@Jenny_Digital]

@@0LoneTech Fair enough, I didn’t know how it was internally managed, that’s not my domain normally. That said, I would expect more writes than promised because there’s the trust element and the middle of the wafer is usually better than the edges. I just have curiosity galore.

[@rafa_br34]

Why don't they use flash memory instead of an EEPROM?

[@AnotherMaker]

Both do have limited write cycles. These chips were invented long before makers got ahold of them also. I'm guessing that's what works best for the things they were actually designed to do and the Arduino people just repurposed them. A lot of the newer boards do support SD built in.

[@williamlouie569]

You just killed the EEPROM. The rest of the Arduino still functioning?

[@AnotherMaker]

Technically but I can't upload new code to it

[@vitalic_drms]

1:00 cat is helping

[@AnotherMaker]

haha. I only had one opportunity to open a brand new one on camera and she had to steal the show. :)