Waht happens if an AVR device is programmed to often so that the garanteed number of flash erase/wirte cycles is exceeded?
This may get an issue when heavily using debugwire to debug programms. Atmel suggested not shipping those chips used for heavy debuggnig to custummers.
The Question now is what errors to expect and maybe how to detect a worn out flash ?
What happens if flash is writen to often ?
There comes a point where some of the bits cannot be returned to 1 in the erase cycle so instead of the device being cleared to all 0xFF some bytes may be 0x7F or 0xEF or something. When they are subsequently programmed you may be OK if the affected bit is due to be 0 anyway but if it's supposed to be 1 you have a problem.
But why on earth would you be considering shipping a prototyping IC to a customer anyway?!?!? Are your costs really THAT tight that you cannot afford a brand new device for each unit you build?
Is there some way of telling how many FLASH erase cycles have been used so far? Getting nervous about my current testing pair of TINY2313s. Got these as samples from Atmel (not available in the local shops) so I don't have spares to put in when I can't program these any more.
Is there some way of telling how many FLASH erase cycles have been used so far?
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.
you order the $2 2313 replacement
plus shipping and handling. :P And make that week 20 - stuff takes a while to get here.
Maybe Atmel should reserve a section of the EEPROM for keeping track of this number. Then the programmer could increment a value there, and tell the user about it as well.
Dash it, if my inkjet printer cartridge can do it why not the AVR?
PonyProg and probably other programming software can increment a serial number placed at an adress of your choice.
Maybe Atmel should reserve a section of the EEPROM for keeping track of this number.
Atmel has reserved the entire EEPROM for you to do whatever you want with it.
'I flash 10 times an hour, 8 hours a day, 5 days a week'
In NYC this is considered a felony :lol:
Jim
Quote:'I flash 10 times an hour, 8 hours a day, 5 days a week'In NYC this is considered a felony :lol:
Jim
Ok that there is funny! Thanks for the laugh.
jgmdesign wrote:Quote:'I flash 10 times an hour, 8 hours a day, 5 days a week'In NYC this is considered a felony :lol:
Jim
Ok that there is funny! Thanks for the laugh.
If one flashed in private, would anyone care?
Maybe Atmel should reserve a section of the EEPROM for keeping track of this number.
What number? Do you want to count the number of FLASH pages written? What will the number 10K writes tell you? That you wrote to the same FLASH page 10K times (and it might be on the verge of wearing out)? Or does it mean that you've written 10K pages, but distributed over the entire FLASH (The ATtiny2313 has has 2KB of FLASH, every page being 32 bytes making for 64 pages, and thus 10K writes distributed over all pages would mean just over 150 writes per page giving you at least 9850 writes left)?
Yes, Atmel could have one count per page.. :shock:
Seruiously: When you lab AVR starts to act crazy, replace it. Always use fresh AVRs for products you're shipping (fresh could mean that you've stress-tested them etc in-house for a while).
I agree with Johan. I never send out anything with a lab micro in it. What I do is test the hell out of the device, then program a fresh device and test the hell out of that. Then I send that one out. The lab unit never leaves the house.
Jim
Hey! Atmel only gave me two of these. I'm currently trying to interface a peripheral chip that has poor/vague documentation, so I'm having to do shotgun programming - I change something in the code and then load it in the AVR to see if it works. This technique uses write cycles at an alarming rate. :( The damn peripheral has 11 9bit configuration registers.
I too keep my prototypes close to home, but here I'm afraid of the prototype itself dying on me.
I wasn't commenting on your predicament. I was commenting on the technical difficulties of keeping some kind of count on FLASH erase/write cycles.
Atmel only gave me two of these.
So? Buy some more.
This technique uses write cycles at an alarming rate. Sad The damn peripheral has 11 9bit configuration registers.
When trying to figure out a complex undocumented protocol it can sometimes help using a little creativity. You could make a second link to a PC that would be nothing more than a feed through until you figure it out.
The cost of sacrificial development chips, and prototypes should be in your development costs. This is simply just part of the cost of development.
I too am with Johan in that you should never send out a lab chip to a customer on a prototype, though as stated, lightly used chips are ok for a prototype. On a production board the chip should always be new. The only usage on a production board should be for production qualification testing. The chip should never be one that has been recycled form other testing.
So? Buy some more.
I would if I could. Haven't found a local shop that sells these. I have to either go to Atmel or someone like DigiKey. My shopping list isn't big enough for DigiKey yet - must buy enough stuff in one shipment to spread out the shipping and handling charges. Anyway, I have a friend in Mumbai - maybe he'll have better luck in the shops there.
Try ebay.
There are some nice application notes on the Atmel website that cover all this, including keeping track with the EEPROM.
Smiley
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.
AVRdude has the option to use the eeprom (I think its the last 4 bytes) to count the number of flash erases. Since one usually reprograms the first flash page every time it count als erase cylces.
The programming tool inside the BASCOM basic. Counts the total number of cycles in PC. This helps to get a feeling how often you realy reprogram. The number of cycles was more a problem with the older AT90.. chips, specified for 1000 cycles instead of 10000. And don't expect the chip to break down on cycle 10001, this is not an excact limt. Extentensive use of debuging (with breakpoints) via debugwire is probably the ony practical way to wear out the flash. With so many normal programming cycles I would also start to worry about the lifetime of the ISP connectors.
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 bits may not falter immediately, but their retention time is reduced.
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
why don't we hear much about write-life disclaimers for the thumb drives we all use?
May be the memory consumed by this thread is more than this wearing out 2K flash of that damn ATtiny2313!
Buy ur self new chips, ain't that difficult. I don't find much AVR range in the local shops neither ur worries justified, thu I find a way around this issue.. THEN.. there are numerous ways to buying AVR chips, itch ur pocket and it will be easy for ya, don't depend on samples if u really wanna work on AVR buddy!
Quote:
So? Buy some more.
I would if I could. Haven't found a local shop that sells these. I have to either go to Atmel or someone like DigiKey. My shopping list isn't big enough for DigiKey yet - must buy enough stuff in one shipment to spread out the shipping and handling charges. Anyway, I have a friend in Mumbai - maybe he'll have better luck in the shops there.
Could I suggest that you buy from futurlec? Just around the corner from you, very reasonable prices, small quantities allowed and virtually no delivery cost by comparison with other suppliers. I have used them many times.
Cheers,
Thanks guys. I think this site will do for me:
http://robokits.co.in/ :D
I'm curious as to weather shipping from Japan would be cheaper than shipping from America. I can try and get a shipping quote from a parts shop there if you like.
Thanks for the kind offer, but the robokits site is based in India in Baroda, just some 1039 km from Delhi. Practically local. :roll: Price approx $1.50, shipping and courier charges approx $1.50 (both in single quantities). Not bad I'd say. :D