Post by thread:[PIC] 16F88 EE Corruption?

I have a design that uses a 16F88. The code is very similar to a few other products but they use a 16F628A or 16F648A. I'm having problems with this one design where in the field the EE is being erased. (I think) When I read the offending EE back (via MPLAB), the data is FF instead of its usual 00 .. 07 range. I've gone over the code numerous times and checked the write sequence. I can't even reproduce the fault back here. It can take days or months to show up in the field. I don't know if more than one location is being erased as I'm only storing and reading one byte. (the first one) Has anyone come across this before? David... -- ___________________________________________ David Duffy Audio Visual Devices P/L Unit 8, 10 Hook St, Capalaba 4157 Australia Ph: +61 7 38235717 Fax: +61 7 38234717 Our Web Site: http://www.audiovisualdevices.com.au ___________________________________________

Dave, Atmel had a problem with some of their AtMega chips. They recommended that the first EEPROM location not be used. IIRC it could get corrupted when the chip power supply died or glitched. Have you tried using a different address? RP 2009/9/30 David Duffy (AVD) <spam_OUTdavidTakeThisOuTaudiovisualdevices.com.au>: {Quote hidden}> I have a design that uses a 16F88. The code is very similar to a few > other products but they use a 16F628A or 16F648A. > > I'm having problems with this one design where in the field the EE is > being erased. (I think) When I read the offending EE back (via MPLAB), > the data is FF instead of its usual 00 .. 07 range. > > I've gone over the code numerous times and checked the write sequence. I > can't even reproduce the fault back here. It can take days or months to > show up in the field. > > I don't know if more than one location is being erased as I'm only > storing and reading one byte. (the first one) Has anyone come across > this before? > David... > > -- > ___________________________________________ > David Duffy Audio Visual Devices P/L > Unit 8, 10 Hook St, Capalaba 4157 Australia > Ph: +61 7 38235717 Fax: +61 7 38234717 > Our Web Site: http://www.audiovisualdevices.com.au > ___________________________________________ > >

David Duffy (AVD) wrote: > I have a design that uses a 16F88. The code is very similar to a few > other products but they use a 16F628A or 16F648A. > > I'm having problems with this one design where in the field the EE is > being erased. (I think) When I read the offending EE back (via MPLAB), > the data is FF instead of its usual 00 .. 07 range. > > I've gone over the code numerous times and checked the write sequence. I > can't even reproduce the fault back here. It can take days or months to > show up in the field. > > I don't know if more than one location is being erased as I'm only > storing and reading one byte. (the first one) Has anyone come across > this before? > David... > > David, this is pretty common in the "nanowatt" series of PICs. This is caused by weaknesses in the EEPROM manufactrung process. It turns out that, unlike the older PIC16C/18C, there are now severe limitations on the number of times the EEPROM cell can be read before being refreshed. Unfortunately, frequent refreshes reduce the useful lifetime of the EEPROM cell. My solution is to write critical values 3-5 times, then read with a "best 3 of 5" algorithm. The idea is that if all 5 match, use the first value found, but if any of the 5 are different, rewrite all 5, using the value that at least 3 of the 5 match, before proceeding. This limits over-refreshing, and only refreshes the cells that NEED to be refreshed. --Bob

Bob Axtell wrote: {Quote hidden}> David Duffy (AVD) wrote: > >> I have a design that uses a 16F88. The code is very similar to a few >> other products but they use a 16F628A or 16F648A. >> >> I'm having problems with this one design where in the field the EE is >> being erased. (I think) When I read the offending EE back (via MPLAB), >> the data is FF instead of its usual 00 .. 07 range. >> >> I've gone over the code numerous times and checked the write sequence. I >> can't even reproduce the fault back here. It can take days or months to >> show up in the field. >> >> I don't know if more than one location is being erased as I'm only >> storing and reading one byte. (the first one) Has anyone come across >> this before? >> David... >> >> >> > David, this is pretty common in the "nanowatt" series of PICs. This is > caused by weaknesses in the EEPROM > manufactrung process. It turns out that, unlike the older PIC16C/18C, > there are now severe limitations on the > number of times the EEPROM cell can be read before being refreshed. > Unfortunately, frequent refreshes reduce > the useful lifetime of the EEPROM cell. > > My solution is to write critical values 3-5 times, then read with a > "best 3 of 5" algorithm. The idea is that if all 5 > match, use the first value found, but if any of the 5 are different, > rewrite all 5, using the value that at least 3 of > the 5 match, before proceeding. This limits over-refreshing, and only > refreshes the cells that NEED to be refreshed. > I wasn't aware of this problem until now. It's odd that I've never encountered this with the 16F628A / 648A devices. I'll have to check more carefully, but I don't think the read/write ratio of the EE cell concerned is all that high. Maybe < 10 reads between every 1 write to the same cell at a guess. For now I've done away with the EE, and will just read / write the current status to RAM. It doesn't change very often - maybe only a few times each day. The main reason the EE was used was to persist the unit's status if it was power cycled, but this shouldn't happen very often anyway. I have now coded it so that it defaults back to the "closed mode" (it's a window controller) upon power-up to lessen security issues. I will try a different EE cell on a spare unit, and try to leave that running for as long as I can (weeks / months) so see what happens. David... -- ___________________________________________ David Duffy Audio Visual Devices P/L Unit 8, 10 Hook St, Capalaba 4157 Australia Ph: +61 7 38235717 Fax: +61 7 38234717 Our Web Site: http://www.audiovisualdevices.com.au ___________________________________________

Bob Axtell escreveu: {Quote hidden}> David Duffy (AVD) wrote: > >> I have a design that uses a 16F88. The code is very similar to a few >> other products but they use a 16F628A or 16F648A. >> >> I'm having problems with this one design where in the field the EE is >> being erased. (I think) When I read the offending EE back (via MPLAB), >> the data is FF instead of its usual 00 .. 07 range. >> >> I've gone over the code numerous times and checked the write sequence. I >> can't even reproduce the fault back here. It can take days or months to >> show up in the field. >> >> I don't know if more than one location is being erased as I'm only >> storing and reading one byte. (the first one) Has anyone come across >> this before? >> David... >> >> >> > David, this is pretty common in the "nanowatt" series of PICs. This is > caused by weaknesses in the EEPROM > manufactrung process. It turns out that, unlike the older PIC16C/18C, > there are now severe limitations on the > number of times the EEPROM cell can be read before being refreshed. > Gosh! Now the EEPROMs have maximum number of reads also? Soon they will be worthless if they involve this way. > Unfortunately, frequent refreshes reduce > the useful lifetime of the EEPROM cell. > Refresh is only needed when some cells are written too often and others much seldom. The less frequently written cells start to loose their charge. He says he is using just one addresss, so refresh should not be needed. > My solution is to write critical values 3-5 times, then read with a > "best 3 of 5" algorithm. The idea is that if all 5 > match, use the first value found, but if any of the 5 are different, > rewrite all 5, using the value that at least 3 of > the 5 match, before proceeding. This limits over-refreshing, and only > refreshes the cells that NEED to be refreshed. > > --Bob > __________________________________________________ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/

David Duffy (AVD) wrote: > The main reason the EE was used was to persist the unit's status if it > was power cycled, How about keep the live value in RAM and write it to EEPROM only on power down? It only takes a few milliseconds to write to the EEPROM. You need to detect input power going away, and have a large enough cap on Vdd to keep it running for the few ms it takes to detect the power gone signal and save the live values in EEPROM. As a quick example of the cap value, let's say it needs to provide 10mA for 10mS with no more than 1V droop. 10mA 10mS --------- = 100uF 1V You probably have that much on your power supply already. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Olin Lathrop escreveu: {Quote hidden}> David Duffy (AVD) wrote: > >> The main reason the EE was used was to persist the unit's status if it >> was power cycled, >> > > How about keep the live value in RAM and write it to EEPROM only on power > down? It only takes a few milliseconds to write to the EEPROM. You need to > detect input power going away, and have a large enough cap on Vdd to keep it > running for the few ms it takes to detect the power gone signal and save the > live values in EEPROM. > > As a quick example of the cap value, let's say it needs to provide 10mA for > 10mS with no more than 1V droop. > > 10mA 10mS > --------- = 100uF > 1V > > You probably have that much on your power supply already. > I use this method a lot, it works extremely well. Just connect an interrupt pin (with proper circuitry of course) to a point before the voltage regulator or the like, this way you will get a much early interrupt. Don't forget that the device usually wok with voltages much lower than the ones they are usually powered (some PICs are powered with 5V but work down to 3V or less), this may help. For dsPICs I use the internal brown-out interrupt so I don't need any external circuitry, but smaller PICs have only brown-out reset and won't work without external aid, unless you use the voltage comparator (for the ones that have it). Best regards, Isaac __________________________________________________ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/

This is only for the PICs. The external EEPROMs are, frankly, bulletproof. Microchip has released a weasel-worded solution, but it it makes almost no sense to refresh all of the cells needlessly. --Bob A {Quote hidden}> Bob, > I didn't experience this problem (yet) but it is good to know. I > understand > this is for the EEPROM part of the MCU and not for the FLASH, correct? > Is this a problem on the "external" I2C EEPROM series from Microchip as > well > or only on the nanowatt MCU series? > > TIA > > 2009/9/30 Bob Axtell <EraseMEengineerspam_OUTTakeThisOuTcotse.net> > >> David, this is pretty common in the "nanowatt" series of PICs. This is >> caused by weaknesses in the EEPROM >> manufactrung process. It turns out that, unlike the older PIC16C/18C, >> there are now severe limitations on the >> number of times the EEPROM cell can be read before being refreshed. >> Unfortunately, frequent refreshes reduce >> the useful lifetime of the EEPROM cell. >> >> > > -- > Ariel Rocholl > Madrid, Spain > -

Quoting Bob Axtell <engineerspam_OUTcotse.net>: > > This is only for the PICs. The external EEPROMs are, frankly, bulletproof. > > Microchip has released a weasel-worded solution, but it it makes almost no > sense to refresh all of the cells needlessly. > > --Bob A Apparently this same problem occurs in SSDs, requiring refresh cycles. {Quote hidden}>> Bob, >> I didn't experience this problem (yet) but it is good to know. I >> understand >> this is for the EEPROM part of the MCU and not for the FLASH, correct? >> Is this a problem on the "external" I2C EEPROM series from Microchip as >> well >> or only on the nanowatt MCU series? >> >> TIA >> >> 2009/9/30 Bob Axtell <@spam@engineerKILLspamcotse.net> >> >>> David, this is pretty common in the "nanowatt" series of PICs. This is >>> caused by weaknesses in the EEPROM >>> manufactrung process. It turns out that, unlike the older PIC16C/18C, >>> there are now severe limitations on the >>> number of times the EEPROM cell can be read before being refreshed. >>> Unfortunately, frequent refreshes reduce >>> the useful lifetime of the EEPROM cell. >>> >>> >> >> -- >> Ariel Rocholl >> Madrid, Spain >> --

Olin Lathrop wrote: > David Duffy (AVD) wrote: > >> The main reason the EE was used was to persist the unit's status if it >> was power cycled, >> > > How about keep the live value in RAM and write it to EEPROM only on power > down? It only takes a few milliseconds to write to the EEPROM. You need to > detect input power going away, and have a large enough cap on Vdd to keep it > running for the few ms it takes to detect the power gone signal and save the > live values in EEPROM. > I had considered that, but the hardware is already deployed so no chance to mod the circuit. A replacement chip is possible, but that's the limit on what can be done in the field. Also, there are no spare pins available for the detection. David... -- ___________________________________________ David Duffy Audio Visual Devices P/L Unit 8, 10 Hook St, Capalaba 4157 Australia Ph: +61 7 38235717 Fax: +61 7 38234717 Our Web Site: http://www.audiovisualdevices.com.au ___________________________________________

Bob, Do you have more information about this? My reading of the Mchip docs suggests that the problem is not reads but writes to one cell affecting other cells in the array, so that writing address 0 and then writing address 1 10,000 times, if I try to then read address 0, I may get garbled data - so I need to make sure the refresh address 0 after every N writes to any cell in the array. In other words, if I simply write data once, I should then be able to read it indefinitely with no further refreshes. Sean On Wed, Sep 30, 2009 at 4:50 AM, Bob Axtell <KILLspamengineerKILLspamcotse.net> wrote: {Quote hidden}> David Duffy (AVD) wrote: >> I have a design that uses a 16F88. The code is very similar to a few >> other products but they use a 16F628A or 16F648A. >> >> I'm having problems with this one design where in the field the EE is >> being erased. (I think) When I read the offending EE back (via MPLAB), >> the data is FF instead of its usual 00 .. 07 range. >> >> I've gone over the code numerous times and checked the write sequence. I >> can't even reproduce the fault back here. It can take days or months to >> show up in the field. >> >> I don't know if more than one location is being erased as I'm only >> storing and reading one byte. (the first one) Has anyone come across >> this before? >> David... >> >> > David, this is pretty common in the "nanowatt" series of PICs. This is > caused by weaknesses in the EEPROM > manufactrung process. It turns out that, unlike the older PIC16C/18C, > there are now severe limitations on the > number of times the EEPROM cell can be read before being refreshed. > Unfortunately, frequent refreshes reduce > the useful lifetime of the EEPROM cell. > > My solution is to write critical values 3-5 times, then read with a > "best 3 of 5" algorithm. The idea is that if all 5 > match, use the first value found, but if any of the 5 are different, > rewrite all 5, using the value that at least 3 of > the 5 match, before proceeding. This limits over-refreshing, and only > refreshes the cells that NEED to be refreshed. > > --Bob > -

Sean Breheny wrote: > Bob, > > Do you have more information about this? My reading of the Mchip docs > suggests that the problem is not reads but writes to one cell > affecting other cells in the array, so that writing address 0 and then > writing address 1 10,000 times, if I try to then read address 0, I may > get garbled data - so I need to make sure the refresh address 0 after > every N writes to any cell in the array. In other words, if I simply > write data once, I should then be able to read it indefinitely with no > further refreshes. > > Sean > > I thought this was settled years ago; the PICforum and the PIClist should all have archives on it. Trust me, if you did nothing but read EEPROM data repeatedly, in a few days, the data will be corrupted, regardless of where it is in the array. And yes, there is interaction with other data in close proximity. The read process, like the write process, slowly erodes the data, as does other lesser-occurring effects, such as radiation, cosmic rays, heat, etc. In years past, PICs were made with thicker interconnections and better isolation for the EEPROM arrays, and errors in EEPROM data was almost unheard of. But as the devices have become smaller and the protection less, the "dark side" of smaller die sizes begins to show up. Refresh it en masse as Microchip recommends, or use my "best of" algorithm and refresh it as needed. My algorithm just increases cell life. --Bob

Bob, Can you elaborate on your method of refreshing? Or a link to what Microchip recommends? This may be one of my problems I have been fighting with a client. --- On Mon, 10/5/09, Bob Axtell <RemoveMEengineerTakeThisOuTcotse.net> wrote: {Quote hidden}> From: Bob Axtell <spamBeGoneengineerspamBeGonecotse.net> > Subject: Re: [PIC] 16F88 EE Corruption? > To: "Microcontroller discussion list - Public." <TakeThisOuTpiclistEraseMEspam_OUTmit.edu> > Date: Monday, October 5, 2009, 7:57 AM > Sean Breheny wrote: > > Bob, > > > > Do you have more information about this? My reading of > the Mchip docs > > suggests that the problem is not reads but writes to > one cell > > affecting other cells in the array, so that writing > address 0 and then > > writing address 1 10,000 times, if I try to then read > address 0, I may > > get garbled data - so I need to make sure the refresh > address 0 after > > every N writes to any cell in the array. In other > words, if I simply > > write data once, I should then be able to read it > indefinitely with no > > further refreshes. > > > > Sean > > > > > I thought this was settled years ago; the PICforum and the > PIClist > should all have archives on it. > Trust me, if you did nothing but read EEPROM data > repeatedly, in a few > days, the data will be > corrupted, regardless of where it is in the array. And yes, > there is > interaction with other data > in close proximity. The read process, like the write > process, slowly > erodes the data, as does > other lesser-occurring effects, such as radiation, cosmic > rays, heat, etc. > > In years past, PICs were made with thicker interconnections > and better > isolation for the EEPROM > arrays, and errors in EEPROM data was almost unheard of. > But as the > devices have become smaller > and the protection less, the "dark side" of smaller die > sizes begins to > show up. > > Refresh it en masse as Microchip recommends, or use my > "best of" > algorithm and refresh it as needed. > My algorithm just increases cell life. > > --Bob > -

Thanks...I did miss what he wrote. I sometimes only check this once a week so sometimes its easy to miss something. --- On Fri, 10/9/09, Barry Gershenfeld <gbarry42EraseME.....gmail.com> wrote: {Quote hidden}> From: Barry Gershenfeld <EraseMEgbarry42gmail.com> > Subject: Re: [PIC] 16F88 EE Corruption? > To: "Microcontroller discussion list - Public." <RemoveMEpiclistEraseMEEraseMEmit.edu> > Date: Friday, October 9, 2009, 12:28 PM > On Fri, Oct 9, 2009 at 7:48 AM, alan > smith <RemoveMEmicro_eng2spam_OUTKILLspamyahoo.com> > wrote: > > > Bob, > > > > Can you elaborate on your method of refreshing? > Or a link to what > > Microchip recommends? This may be one of my > problems I have been fighting > > with a client. > > > > Do you need more than he wrote before? Or it's > possible you missed his > earlier message. Here's what he wrote: > > > > My solution is to write critical values 3-5 times, > then read with a > > "best 3 of 5" algorithm. The idea is that if all 5 > > match, use the first value found, but if any of the 5 > are different, > > rewrite all 5, using the value that at least 3 of > > the 5 match, before proceeding. This limits > over-refreshing, and only > > refreshes the cells that NEED to be refreshed. > > > > --Bob > > > > > -

alan smith wrote: > Bob, > > Can you elaborate on your method of refreshing? Or a link to what Microchip recommends? This may be one of my problems I have been fighting with a client. > > Alan, sorry I didn't answer sooner, I've been busy. I have done this many times, and it works perfectly, on PIC16F88/87, PIC16F877A, a few newer PIC18's. I write the data 5 times, instead of just once. I don't bother to jump all over the array, I simply write 5 times in a row with the same data. When I read, I read 5 bytes instead of just once. I then check all 5 to see if they are the same. A. If all 5 are the same, I use the value and do nothing. B. If all 5 are NOT the same, I locate at least 3 that ARE the same, and use that as the "value", but I then rewrite ALL 5 anyway. C. If worse than best 3 of 5, the data must be considered defective....but I have never had that experience, EVER. The advantage over Microchip's total rewrite scheme is that this method (1) only refreshes the cells that NEED to be refreshed, and (2) doesn't needlessly reduce overall cell life. Think about it...why overstress cells that are working fine? Aside to the List: This brings up a point that Olin and others are trying to make... sometimes Microchip gives some bad advice, like the open outputs to GND. Well here is another one. --Bob A {Quote hidden}> --- On Mon, 10/5/09, Bob Axtell <RemoveMEengineerTakeThisOuTspamcotse.net> wrote: > > >> From: Bob Axtell <EraseMEengineerspamspamBeGonecotse.net> >> Subject: Re: [PIC] 16F88 EE Corruption? >> To: "Microcontroller discussion list - Public." <RemoveMEpiclistKILLspammit.edu> >> Date: Monday, October 5, 2009, 7:57 AM >> Sean Breheny wrote: >> >>> Bob, >>> >>> Do you have more information about this? My reading of >>> >> the Mchip docs >> >>> suggests that the problem is not reads but writes to >>> >> one cell >> >>> affecting other cells in the array, so that writing >>> >> address 0 and then >> >>> writing address 1 10,000 times, if I try to then read >>> >> address 0, I may >> >>> get garbled data - so I need to make sure the refresh >>> >> address 0 after >> >>> every N writes to any cell in the array. In other >>> >> words, if I simply >> >>> write data once, I should then be able to read it >>> >> indefinitely with no >> >>> further refreshes. >>> >>> Sean >>> >>> >>> >> I thought this was settled years ago; the PICforum and the >> PIClist >> should all have archives on it. >> Trust me, if you did nothing but read EEPROM data >> repeatedly, in a few >> days, the data will be >> corrupted, regardless of where it is in the array. And yes, >> there is >> interaction with other data >> in close proximity. The read process, like the write >> process, slowly >> erodes the data, as does >> other lesser-occurring effects, such as radiation, cosmic >> rays, heat, etc. >> >> In years past, PICs were made with thicker interconnections >> and better >> isolation for the EEPROM >> arrays, and errors in EEPROM data was almost unheard of. >> But as the >> devices have become smaller >> and the protection less, the "dark side" of smaller die >> sizes begins to >> show up. >> >> Refresh it en masse as Microchip recommends, or use my >> "best of" >> algorithm and refresh it as needed. >> My algorithm just increases cell life. >> >> --Bob >> --

Thanks Bob. I do best of 3, but perhaps best of 5 is better. The corruption I was seeing...not sure if it was EEPROM corruption or something over writing in RAM. But none the less, good advice --- On Fri, 10/9/09, Bob Axtell <engineerSTOPspamspam_OUTcotse.net> wrote: {Quote hidden}> From: Bob Axtell <spamBeGoneengineerSTOPspamEraseMEcotse.net> > Subject: Re: [PIC] 16F88 EE Corruption? > To: "Microcontroller discussion list - Public." <KILLspampiclistspamBeGonemit.edu> > Date: Friday, October 9, 2009, 6:56 PM > alan smith wrote: > > Bob, > > > > Can you elaborate on your method of refreshing? > Or a link to what Microchip recommends? This may be > one of my problems I have been fighting with a client. > > > > > Alan, sorry I didn't answer sooner, I've been busy. > > I have done this many times, and it works perfectly, on > PIC16F88/87, > PIC16F877A, a few newer PIC18's. > > I write the data 5 times, instead of just once. I don't > bother to jump > all over the array, I simply write 5 times in a row with > the same data. > > When I read, I read 5 bytes instead of just once. I then > check all 5 to > see if they are the same. > A. If all 5 are the same, I use the value and do > nothing. > B. If all 5 are NOT the same, I locate at least 3 that ARE > the same, and > use that as the "value", but I > then rewrite ALL 5 anyway. > C. If worse than best 3 of 5, the data must be considered > defective....but I have never had that experience, EVER. > > The advantage over Microchip's total rewrite scheme is that > this method > (1) only refreshes the cells that NEED to > be refreshed, and (2) doesn't needlessly reduce overall > cell life. Think > about it...why overstress cells that are working > fine? > > > Aside to the List: > > This brings up a point that Olin and others are trying to > make... > sometimes Microchip gives some bad advice, like the > open outputs to GND. Well here is another one. > > --Bob A > > > --- On Mon, 10/5/09, Bob Axtell <EraseMEengineerEraseMEcotse.net> > wrote: > > > > > >> From: Bob Axtell <@spam@engineer@spam@spam_OUTcotse.net> > >> Subject: Re: [PIC] 16F88 EE Corruption? > >> To: "Microcontroller discussion list - Public." > <spamBeGonepiclistKILLspammit.edu> > >> Date: Monday, October 5, 2009, 7:57 AM > >> Sean Breheny wrote: > >> > >>> Bob, > >>> > >>> Do you have more information about this? My > reading of > >>> > >> the Mchip docs > >> > >>> suggests that the problem is not reads but > writes to > >>> > >> one cell > >> > >>> affecting other cells in the array, so that > writing > >>> > >> address 0 and then > >> > >>> writing address 1 10,000 times, if I try to > then read > >>> > >> address 0, I may > >> > >>> get garbled data - so I need to make sure the > refresh > >>> > >> address 0 after > >> > >>> every N writes to any cell in the array. In > other > >>> > >> words, if I simply > >> > >>> write data once, I should then be able to read > it > >>> > >> indefinitely with no > >> > >>> further refreshes. > >>> > >>> Sean > >>> > >>> > >>> > >> I thought this was settled years ago; the PICforum > and the > >> PIClist > >> should all have archives on it. > >> Trust me, if you did nothing but read EEPROM data > >> repeatedly, in a few > >> days, the data will be > >> corrupted, regardless of where it is in the array. > And yes, > >> there is > >> interaction with other data > >> in close proximity. The read process, like > the write > >> process, slowly > >> erodes the data, as does > >> other lesser-occurring effects, such as radiation, > cosmic > >> rays, heat, etc. > >> > >> In years past, PICs were made with thicker > interconnections > >> and better > >> isolation for the EEPROM > >> arrays, and errors in EEPROM data was almost > unheard of. > >> But as the > >> devices have become smaller > >> and the protection less, the "dark side" of > smaller die > >> sizes begins to > >> show up. > >> > >> Refresh it en masse as Microchip recommends, or > use my > >> "best of" > >> algorithm and refresh it as needed. > >> My algorithm just increases cell life. > >> > >> --Bob > >> --