user32118: 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.

user313: 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.

user29356: 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.

user30005: 
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.

32118: <p>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.</p>

<p>What will happen?</p>

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

<p>Or will it work sometimes, sometimes not?</p>

<p><strong>Example of heavy use:</strong> 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.</p>

<p>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.</p>

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

<p><strong>In conclusion:</strong> 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.</p>
 313: <p>This <a href="https://en.wikipedia.org/wiki/Flash_memory" rel="nofollow noreferrer">Wikipedia article</a> 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.</p>

<p>However...</p>

<p>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.</p>
 29356: <p>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.</p>
 30005: <blockquote>
  <p>What will happen?</p>
</blockquote>

<p>it may not pass parity check. so uploading code wouldn't be possible.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>
