6

I realized that I'm uploading code every 5 minutes and doing relatively intensive trial-and-error development, and that this habit could cause problems down the road, especially if I'm working on a custom board (non-Arduino) where the chip isn't readily replaceable.

What will happen?

I noticed that avrdude verifies the written flash. So will it simply start noticing errors and possibly be unable to write without failing?

Or will it work sometimes, sometimes not?

Example of heavy use: A custom PCB where easy replacement of the MCU is not possible. 10,000 writes would equal 100 days, each 8 hours of development, with flash write every 5 minutes.

I have several habits that drive frequent flash writing: I inject benchmarks into my code, test speed improvements of small optimizations, program size optimizations, and so on.

I now try to restrain myself from flashing too frequently and doing more code revisions before testing, rather than testing immediately.

In conclusion: Yes, it's unlikely, and arguably, if you're working full-time on a board, less intensively, for, say, a year, you can probably afford to buy another board when the first one starts failing the flash-verification.

Improve this question
7
  • 1
    As far as I know, avrdude checks every written byte. You will know when it failed. Some have done tests with the EEPROM, but I don't know a test with Flash. The old ATmega8 has the same numbers for flash (10k) and EEPROM (100k), but the newer chips are better. I suppose it starts failing after many 10k of writing. – Jot Apr 5 '17 at 10:12
  • @Jot, I'm still not sure if the consequence will be corrupted flash, if avrdude will gradually fail more frequently and have to retry, or if the flash will simply be incapable of being written to correctly, e.g. always yield an incorrect reading. – user8437812 Apr 5 '17 at 10:46
  • 1
    The datasheets tend to be conservative, and the numbers they give are usually valid for a wide temperature range. In room temperature conditions, chances are you can go far beyond the 10K cycles limit. You just cannot be 100% certain, as Atmel does not make any promise beyond 10K. – Edgar Bonet Apr 5 '17 at 10:59
  • What I'm trying to ascertain, is how it will fail. – user8437812 Apr 5 '17 at 11:21
  • 1
    Actually, it will be undefined behaviour. Basically anything could happen and it should be avoided to do so. – Paul Apr 5 '17 at 20:13
1

This Wikipedia article about Flash memory discusses failure mechanisms including references to relevant papers. One point that surprised me was "Read Disturbance" of adjacent cells after a large number (>100,000) of reads from one cell since last erase, causing the adjacent cell(s) to read back erroneously. There's probably more there and in the referenced articles than you ever wanted to know about Flash failure mechanisms.

However...

At 5min per test, 10000 tests will take you 35 days working around the clock or 100+ days @8hrs/day, maintaining that rate of testing. My point being that you're not likely to reach 10K cycles. But if you are concerned about putting a heavily used chip in the field (and I might be, too, in some cases), socketing board #1 would be worth your while.

Improve this answer
3
  • Indeed. My concern is mainly in regards to actively developing on a custom PCB, with an ATmega2560 which wouldn't be too much fun to replace manually, although doable (100 pins + risk of hard-to-see short circuit of the pins). Or alternatively, buying several boards. – user8437812 Apr 5 '17 at 14:15
  • The reason for the high number of writes is that I'm fine-tuning various functions for automation, sensing etc. -- perhaps some of that could be alleviated by writing to the EEPROM via serial etc. etc. but that's a lot more complicated than just rebuilding/reflashing ;) – user8437812 Apr 5 '17 at 14:18
  • My first thought is whether any of those functions could be tuned out-of-system? And if not, what is the cost of a failure in the field vs. the steps necessary to prevent one? Will failure cost some downtime? A global service call? A customer relationship? Killing a patient? Some scenarios just simply justify even a huge upfront investment to avoid them. Ouch - talk about the rock vs. the hard place... – JRobert Apr 5 '17 at 14:29
3

What will happen?

it may not pass parity check. so uploading code wouldn't be possible.

with that said, I have never had one flash-based mcu failure due to endurance. that's countless mcus since as far as I can remember.

to give you some sense of design headroom, I wrote-to and then read-back from eeprom on a pic over several hours @ 10ms per read/write, without a failure. that eeprom is rated 1M in endurance.

so unless you get some weird parts or you write to it repeatedly over a long period of time, flash failure is unlikely a practical issue.

Improve this answer
1

Assuming that you don't have to fine tune each board individually, just don't send the board that you do your testing/adjusting to the 'field'.....keep it in-house, and only use new boards for field use.

Improve this answer
1
  • 10k write cycles is a lot though. – Paul Apr 5 '17 at 20:17
0

Although it's not a direct answer to your question, it might be an answer for your problem (the need to do intensive trial-and-error.

Probably you are testing mostly your program (changes), and not your hardware (changes). Since I don't assume you change your hardware (breadboard) every 5 minutes.

In case the program is quite complicated, probably it will be best to write a specific off-line test program, and run it on a computer instead of an Arduino. You probably have to stub some classes/libraries you use, but it might save you a lot of time. Also you have the benefit of a better IDE and many more debug possibilities. After the tests on the offline test program pass, you try it on the Arduino.

This way you probably need to upload the program just a few times per day on the Arduino.

Improve this answer
3
  • In my experience, this would be better suited as a comment than an answer. – user8437812 Apr 5 '17 at 10:43
  • 2
    I think it depends on what is more important: the answer of the question itself or the solution of his problem. – Michel Keijzers Apr 5 '17 at 11:01
  • 1
    It is a good answer, because 10k trials is too much and it is better to fix the underlying problem. Perhaps delays are used which needs to be tuned (instead of using millis). Perhaps more than one Arduino board can be used, or Arduino Due with multiple tasks. I think that only a random generator to create working code would require so many trials. – Jot Apr 5 '17 at 23:03
0

AFAIK the manufacturer say, that the number of write cycles is guaranteed. Usually the chip is able to endure little more (for manufacturer to be safe to keep the guarantee), individual chips may, on random, endure much, much more.

Also the failure can result in two kinds of problems - first one is better in a way - the write just fail, following read returns "something" (usually part of written value, but some bits always set to the same 0/1). The second one is, that the wearing makes the write unreliable - you write it, you read it it is ok, but after some time (like days/months) the content is changed and if you read it again, you will get "something" as in previous case.

It would be better to make sure you are able to exchange the chip, before going to "normal use" and put there fresh one - use a socket/create new board/unsolder old chip and solder new one. Use the weared chip for more testing/developement, but for production use a fresh one with only few cycles of reflashing. Also software emulators could speed up your developement a lot and decrease the need to/number of reflashing the chip on the board.

Improve this answer

Your Answer

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

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