AVR Freaks

Like 'I flash 10 times an hour, 8 hours a day, 5 days a week' (you sound quite busy), then come up with an estimate- 10000/(80*5)= 25 weeks. Then somewhere in weeks 1-24, you order the $2 2313 replacement so it shows up before week 25.

PonyProg and probably other programming software can increment a serial number placed at an adress of your choice.

If one flashed in private, would anyone care?

One thing that may be overlooked, is that 'data retention' decreases as the number of erase/write cycles increase. I have no idea by what amount, though. If you are over 50, you don't have to care much about it anyway (you will be in your motor home or boat somewhere without a care in the world when the 'leaky' avr starts screwing up).

Rather than actually count the number, if I was really concerned, this is what I would do (probably not)-

assuming you are using 'normal' programming (spi/jtag/dw) in which a chip erase takes place, every chip erase will at least change the first few pages (the ones we really care about, and the ones that will wear out first). So what I would do is on every app start, check the last page to see if it is erased (this last page has to be unused of course). If it is, write 0's to the page, erase the page, write 0's to the page again. Which should 'wear' out the last page at twice the rate of the first pages (and give us 8 x pagesize of 'test' cells). So instead of counting, you are actually checking the ability of flash to hold a charge. The 'fudge factor' of x2 should be enough to cover variables like programming more than once before the app runs, resets in the middle of the flash checking procedure, etc.

If the last page starts failing (any 1 cell), the chip erases should start to fail also (assuming the programmer app is actually checking to see if the last page is erased, if not, a little modification to this plan would be needed).

You could also modify this a little to check 'data retention' on the 'test' page, and catch cell leakage problems before it starts to affect the app's cells. Although that would not do much good on a 'production' avr, as it will be written very few times. But I guess you could erase/write the last page a bunch of times (we'll call this 'burn in') before it is 'shipped', then the last page should have more cell leakage and less data retention so you can catch it before the tires go flat on the other pages.

THEN you order the replacement $2 (+shipping) 2313.

I've flashed mega128's and older/smaller chips many, many times. Never a fault. I seem to recall a promise of 10,000 cycles before certain bits falter. That's a lot of crash-and-burn cycles.

The worn flash won't verify during programming, or have short retention and fail later.

When debugging using software breakpoints, the flash wears faster than expected from the program/erase cycles; Setting/unsetting a software breakpoint (as opposed to hw breakpoints) involves erasing and reprogramming the flash page with that location replaced with a BREAK/original instruction.

Flash wear is a difficult parameter to test; It's done mostly by characterization, and given a wide margin. From the manufacturer's point of view 10k is a 'high enough figure', meaning the customers don't ask for more (=buy the competitor's mcu), and it's a low enough figure, based on the destruction of some statistically significant number of devices. Low enough meaning that, say, less than 0.01% failed when written that many times.
What it means is that almost all devices do a lot better than 10k cycles. I've done 150k cycles on a Mega16 on purpose, and it still works well enough. It might be fine, or it may have six days retention. I don't know, and it's not really important since if it fails, I'll replace it. If it sits at the customer site, it's _just slightly_ more expensive.

/Kasper