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.
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..
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...
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 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.
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.
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.
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.
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.
@@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
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 🙂
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...
@@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.
@@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.
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.
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.
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!
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.
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.
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.
Congratulations AnotherMaker, a BIG thumbs up. This is the first UA-cam video I have ever watched were the author (you) has responded to every comment. Thank you.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
@@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?
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 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?
@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.
@@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?
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.
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
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.
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.
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 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.)
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.
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.
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?
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.
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.
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.
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.
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!
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
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
@@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.
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.
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.
@@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 :)
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.
@@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.
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
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 😎👌
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!
@@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.
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
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.
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 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 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.
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...)
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.
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.
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
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
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.
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.
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.
Mileage may very if your writes are spaced out more ie changing the data every couple minutes not in a fast loop. Temperature is also a factor along with longevity. Atmel is really saying at 85C in a worst case scenario you can rely on 100k (or more) writes that will hold in EEPROM for years. If you need more you can use error correcting and load leveling to get way higher. At any rate don’t rely on writes passed 100k for anything important. It will let you down especially if you do 200k writes then expect your last write to survive for years. You will find bits that last for billions of writes and some that die closer to 100k. Typically there is a bell curve in things like this.
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.
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.
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.
Beware that writing is not the same as _over_writing (erasing and then writing). Erase blocks tend to be bigger (sometimes much bigger in NAND). Sometimes the controller is smart enough to only do the erase when bits need to be changed back, sometimes it just doesn't care. So you writing 1 bit might actually be erasing/writing something like 1Kbit. And if you think you can be clever and use different blocks - first make sure that they are not part of the same erase block size (or your work goes in vain) or even worse, make sure that you're not "dirtying" large blocks of the flash by doing this (I am not familiar with EEPROM erase block sizes, but in NAND it can sometimes be in the order of megabytes(!!!)).
Before I saw the video, I thought, with good memory management (I'm not an expert) a 100000 cycles is still in most cases infinite. I also think if you made something and really use it, it will be probably obsolete in 10 years. One can argue: 'well use that arduino for something else'. But I guess, by then there will be a new 'killer ùController' that we will already have purchased just because of wanting it. Nonetheless, very informing video. 👍
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.
Just don't have the time to read all the comments but, if it hasn't been said already, the more conservative 100,000 writes goes hand-in-hand with the advertised 10-year data retention. Even if a chip survives the first 1 million writes of your test, I'll bet it will no longer retain the latest data after 10 years of storage.
well, seriously...since 1998 you are the first one i came to know...that actually test the limits of anything, BRAVO BRAVO BRAVO !!! i will use your code to do it on a mega2560...not just yet...the mega is being tested with 2 vnh5019 attach to it ALLES GUTE !!!
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.
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.
Yep. Absolutely. I don't want to keep killing boards to get a bigger sample size but it's interesting to know that with a few tricks, you can extend the life to basically forever.
So if you need more than a few hundred thousand, you’re best of writing a code to shift the memory across the eeprom to multiply its lifetime. Some combination of Gray code and a twisted ring counter I’d guess.
Seriously I’m watching this whilst on the loo!
This could be my favorite comment ever.
What an amazing coincidence!
When you're reading datasheets while on the throne, thats called preemptive multitasking 😉
@@zombieregime hahaha 😜 brilliant
@@stillness0072 Well.... ideally not. But a dropped semi-colon can lead to a hung up return.....😁
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 ;)
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.
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.
@@_droid Oh! Thank you for the clarification.
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..
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...
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.
Interesting. I hadn't considered that. And obviously I only tested 2 boards, so I would expect results to vary wildly. Thanks for sharing.
@@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.
@@elsekling2552 i imagine you also need to consider operating conditions like temperature.
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.
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.
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.
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.
And here I am. I don't have a clue as to what you just said.
@@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
@@magoolew5131 Haha
C++ doesn't make optimizations when writing to the EEPROM since all registers are declared volatile
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 🙂
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...
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.
@@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.
That'll do pig, that'll do
@@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.
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.
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.
@@AnotherMaker nah u can always order the cables online, however getting them from your local store will probably be difficult haha
This it's what's UA-cam should be used for.
RESPECT 🙏
Thank you kind viewer!
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!
Thank you. I actually have a few more creative ones coming up. I'm trying a little harder. :)
@@AnotherMaker I'm glad you replied! I feel special. Keep it up man! This is the kind of fun content the world needs!
You should write 0x55 and 0xAA for testing the memory
You're absolutely right.
can you explain why 0x55 and 0xAA exactly?
@@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
@@Kurkkulimu But he's writing all 0s or 1s on each cycle, would it really make difference?
@@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
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.
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.
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.
Congratulations AnotherMaker, a BIG thumbs up.
This is the first UA-cam video I have ever watched were the author (you) has responded to every comment.
Thank you.
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!
Cool idea. Nice results. I also see you're an expert in low temp soldering 😎
My hands are just really tough :) And thanks for watching!
Good to know this isn't something I have to worry about in regular use.
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.
A well done scientific process: hypothesis, experiment, conclusion. In less than 3'. Bravo!
Thank you!
You earned my subscription. Im interested to see what tests and videos you release in the future.
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.
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.
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.
Yep. Absolutely. I'd be interested in seeing how much faster it could be written.
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.
@@AnotherMaker is this a challenge!? Because I've got a nano that could probably be sacrificed to the destructive testing gods.... standby...
I have been thinking about this since 1993, never got to do it because a fatal case of procrastination, haha, loving you.
Bah, procrastination can wait...
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 :)
haha
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.
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.
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.
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.
@@AnotherMaker is the entire eeprom dead or if you write to the bits that didn't fail do they still work?
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.
@@kuebbisch You are probably right. I figured they put the fuse settings on a separate block from user EEPROM though. (shrug)
@@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?
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?
I think you're right. I'm definitely doing that test.
Another thing to remember data loss can occur under high tempatures and if left unpowered
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!
Thanks for watching. I've been thinking about it for years too.
Thank you... That was super interesting and relevant to a project I'm working on right now.
Awesome. Glad to hear it. Thanks so much for watching.
Interesting! Also weird that the one got bricked after it failed. Does it happen to draw exceptionally high power?
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?
@@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?
@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.
Thanks for the extra info. And obviously I could do wear leveling to extend the life
@@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?
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.
Absolutely. This didn't have any built in wear leveling to my understanding.
This was a perfect video. Nice work.
Thank you very much!
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
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.
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.
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.
@@AnotherMaker I wrote a personal library to manage the circular addressing mode if you're interested. Let me know.
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...
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.
It is very heat dependent. You could re-run the test at elevated temperatures.
I've been hearing that. I can put one in the air fryer :)
@@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.)
Please, do the same with FLASH memory!
I love it. I'll do it!
So interesting and getting the point fast.
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.
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.
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.
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?
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.
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.
Good job! Thank you!
Thank you and thanks for watching!
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.
Absolutely. You're 100% correct. Thanks for sharing.
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.
Ok. So interesting to know that the whole section died. Tanks for sharing!
Sounds like a good exercise for the ESP as well
It actually does. That's a big money experiment these days :)
2:25 How are you holding the iron from the hot metallic part?
I have tough hands.
Yeah, all nonvolatile solid state memory has a finite life in this manner. This includes all kinds, bubble memory, flash memory, etc!
Absolutely. I guess it's not THAT nonvolatile :)
Thanks for the research
Thanks for watching!
Very interesting. Never tried it. Thanks
Thanks for watching!
Wow. I got this as a *Google Feed* recommend - great job!
Thank you and thank you for watching!
The last quote involving "For Science" completed the video.
Thank you. I'm glad that was appreciated
lmao, I love how you've shared the code like... "Yo, break your own Arduino here!" 😆
haha "for science." In all seriousness, people have suggested a lot of different techniques, so they may want to alter it.
wonderful video makes me feel less shit about my constant arduino reprogramming
Thank you. And yeah, in "normal" situations it will last a lifetime.
I see the good ol’ asbestos fingers soldering technique is still in use.
I used to work in a restaurant :) I burned my hands enough it doesn't matter anymore lol.
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!
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
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
@@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.
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.
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.
@@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 :)
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.
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.
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 ?
He's built different. You wouldn't get it...
About 100 ms.
I have tested this hypnosis more than once.
I used words not normally looked up in a dictionary in all cases.
@@stevemorse5052 Do you mean 'I have tested this hypothesis...'?
@@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.
haha. I have pretty tough hands :) All my solder joints smell like bacon for some reason.
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
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 😎👌
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!
@@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.
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.
I'll take that as a compliment :-)
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
Yeah my second test was a lot closer to a per cell test ... Although they are always written in blocks
What book were you reading?
I like you answer the question quickly
Thank you! I like faster youtube videos, so I try to make mine that way.
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.
I could still read it. It was just not accepting any more writes correctly
Awesome video. 😊 what book is that please?
It was beginning C for Arduino and it's excellent. My favorite Arduino book. amzn.to/378pEiy
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.
Yeah. That will do it. It's nice to know it could take some cycles at 5v though.
@@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.)
Why not just step down the voltage from 5 to 3.3 V? (and use level converters for logic)
@@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.
@@haruki_nyan I think you can do it!
Fair answer, though.
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.
Sorry for your loss. Yeah. I want to figure out what exactly died on these.
Wow it's cool; would you suggest the book to read;
Thank you. This is the book. It's not cheap, but it's very good. amzn.to/378pEiy
I've always wanted to test this. Thanks mate ❤️🤣.
Pls Do the same with esp8266 and esp32 too 😬
I will probably sacrifice a few other boards in some testing.
Those boards use similar external spi flash chips so killing them might not be as bad as killing the eeprom on a mega328p.
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...)
Yeah. I've been thinking through a good test for the program flash.
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.
Thanks for watching, Norm. This is the book. It's a little cheaper used. Either way it's excellent. amzn.to/378pEiy
@@AnotherMaker much obliged, thanks. I like to keep a stock of good books.😉
Cheers,
Norm.
Just curious, but did you try replacing the controller chip to restore the Nano to service?
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.
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.
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.
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
Yeah. I felt exactly the same way.
It stopped working entirely? Wow!
The one did. I'm going to do an autopsy to figure out what died.
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
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.
Can you still use the arduinos for stuff that does not require an EEPROM or do the go completely poof?
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.
It would be interesting to see if writing random bit values each time actually has influence on the chips health.
I'm definitely doing that in my next test.
Did that soldering at the end smell like bacon? :)
That's how I know I did it right :)
However, you should do the tests at extreme temperatures and voltages.
I'm totally down for torturing a few more boards. :)
OOOOH I like this idea a LOT. Also humidities maybe?
Great idea! Leave one battery powered on a fridge, another one on an oven.
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.
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.
Mileage may very if your writes are spaced out more ie changing the data every couple minutes not in a fast loop. Temperature is also a factor along with longevity.
Atmel is really saying at 85C in a worst case scenario you can rely on 100k (or more) writes that will hold in EEPROM for years.
If you need more you can use error correcting and load leveling to get way higher. At any rate don’t rely on writes passed 100k for anything important. It will let you down especially if you do 200k writes then expect your last write to survive for years.
You will find bits that last for billions of writes and some that die closer to 100k. Typically there is a bell curve in things like this.
Absolutely. Data longevity after writing and the temperature while writing are huge factors.
Earned a sub from me... cheers for your sacrifice.
Thank you so much. They died an honorable death.
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.
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.
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.
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.
Very funny intro😂
Press F to pay respect
Ahh. Thank you :)
This is telling me that I will accidentally step on mine *waaaay* before it breaks from wear and tear from writing to it.
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.
I wonder if there is any option the read out the health of the EEPROM (like the SSD drives)?
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.
Beware that writing is not the same as _over_writing (erasing and then writing). Erase blocks tend to be bigger (sometimes much bigger in NAND). Sometimes the controller is smart enough to only do the erase when bits need to be changed back, sometimes it just doesn't care. So you writing 1 bit might actually be erasing/writing something like 1Kbit. And if you think you can be clever and use different blocks - first make sure that they are not part of the same erase block size (or your work goes in vain) or even worse, make sure that you're not "dirtying" large blocks of the flash by doing this (I am not familiar with EEPROM erase block sizes, but in NAND it can sometimes be in the order of megabytes(!!!)).
You're absolutely right. I've been learning more and more about this. Thanks for sharing.
Before I saw the video, I thought, with good memory management (I'm not an expert) a 100000 cycles is still in most cases infinite. I also think if you made something and really use it, it will be probably obsolete in 10 years. One can argue: 'well use that arduino for something else'. But I guess, by then there will be a new 'killer ùController' that we will already have purchased just because of wanting it.
Nonetheless, very informing video. 👍
Thank you. Yeah. I think if you use it intelligently, you could easily write to the eeprom for the useful life of the device.
awesome!
Thank you! Cheers!
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.
I do want to test that. It would take a little longer though.
Just don't have the time to read all the comments but, if it hasn't been said already, the more conservative 100,000 writes goes hand-in-hand with the advertised 10-year data retention. Even if a chip survives the first 1 million writes of your test, I'll bet it will no longer retain the latest data after 10 years of storage.
Yep. Data retention is the next thing I'm looking at.
Gotta love empirical testing
I could do more, but it's nice to put a number to it. Thanks for watching!
But how many licks does it take to get to the center of a tootsie pop?
105 :)
well, seriously...since 1998 you are the first one i came to know...that actually test the limits of anything, BRAVO BRAVO BRAVO !!! i will use your code to do it on a mega2560...not just yet...the mega is being tested with 2 vnh5019 attach to it
ALLES GUTE !!!
haha. Thanks! This video is part of a playlist called Will it Blow Up? Where I do a few other limit-testing things on the Arduino.
Why did the arduino died after killing its eeprom bytes? For the informations I got, arduino can run without the eeprom functional.
Thank you
Yes. That is my plan. I will report back.
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.
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.
It's usually specified as "guaranteed 100k". Manufacturers have to be careful. Say if the chip crashed a car and killed someone.
Yep. Absolutely. I don't want to keep killing boards to get a bigger sample size but it's interesting to know that with a few tricks, you can extend the life to basically forever.
1:00 cat is helping
haha. I only had one opportunity to open a brand new one on camera and she had to steal the show. :)
Holding a soldering iron like that is easy. Try holding an acetylene torch at the flame!
That may be my next trick!
Sip of coffee (it's 9am) for the two poor dead arduinos that gave their life for science
Thank you for your condolences. They were great boards.
this is sick
Thanks :)
So if you need more than a few hundred thousand, you’re best of writing a code to shift the memory across the eeprom to multiply its lifetime. Some combination of Gray code and a twisted ring counter I’d guess.
Absolutely. I'm going to be talking about that in a future video.