16F88 EE Corruption?

[David Duffy (AVD)]

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: [phone]      Fax: [phone]
Our Web Site: www.audiovisualdevices.com.au
___________________________________________

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Richard Prosser]

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) <david@...>:

> 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: [phone]      Fax: [phone]
> Our Web Site: www.audiovisualdevices.com.au
> ___________________________________________
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[MicroControllers - PIC mailing list]

In message <d02e69350909300040k4f2b267dwb82f1bf9c914cb4@...>,
Richard Prosser <rhprosser@...> writes
>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?
Or perhaps writing to a few addresses (which I appreciate may alter the
problem in itself but...) to try and isolate a code problem from a
hardware problem?
>
>RP
>

--
Clint Sharp
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Bob Axtell]

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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[David Duffy (AVD)]

Bob Axtell wrote:

> 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: [phone]      Fax: [phone]
Our Web Site: www.audiovisualdevices.com.au
___________________________________________

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Isaac Marino Bavaresco]

Bob Axtell escreveu:

> 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/ 
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

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
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[arocholl]

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 <engineer@...>

> 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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Isaac Marino Bavaresco]

Olin Lathrop escreveu:

> 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/ 
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Bob Axtell]

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

> 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 <engineer@...>
>
>> 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
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Spehro Pefhany]

Quoting Bob Axtell <engineer@...>:

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

>> 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 <engineer@...>
>>
>>> 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
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[David Duffy (AVD)]

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: [phone]      Fax: [phone]
Our Web Site: www.audiovisualdevices.com.au
___________________________________________

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Sean Breheny]

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 <engineer@...> wrote:

> 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
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Bob Axtell]

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
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan Smith-10]

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 <engineer@...> wrote:

> From: Bob Axtell <engineer@...>
> Subject: Re: [PIC] 16F88 EE Corruption?
> To: "Microcontroller discussion list - Public." <piclist@...>
> 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
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

     

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Barry Gershenfeld-2]

On Fri, Oct 9, 2009 at 7:48 AM, alan smith <micro_eng2@...> 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
>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan Smith-10]

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 <gbarry42@...> wrote:

> From: Barry Gershenfeld <gbarry42@...>
> Subject: Re: [PIC] 16F88 EE Corruption?
> To: "Microcontroller discussion list - Public." <piclist@...>
> Date: Friday, October 9, 2009, 12:28 PM
> On Fri, Oct 9, 2009 at 7:48 AM, alan
> smith <micro_eng2@...>
> 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
> >
> >
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

     

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Bob Axtell]

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 <engineer@...> wrote:
>
>  
>> From: Bob Axtell <engineer@...>
>> Subject: Re: [PIC] 16F88 EE Corruption?
>> To: "Microcontroller discussion list - Public." <piclist@...>
>> 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
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>>    
>
>
>      
>
>  

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Alan Smith-10]

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 <engineer@...> wrote:

> From: Bob Axtell <engineer@...>
> Subject: Re: [PIC] 16F88 EE Corruption?
> To: "Microcontroller discussion list - Public." <piclist@...>
> 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 <engineer@...>
> wrote:
> >
> >   
> >> From: Bob Axtell <engineer@...>
> >> Subject: Re: [PIC] 16F88 EE Corruption?
> >> To: "Microcontroller discussion list - Public."
> <piclist@...>
> >> 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
> >> --
> >> http://www.piclist.com PIC/SX FAQ & list archive
> >> View/change your membership options at
> >> http://mailman.mit.edu/mailman/listinfo/piclist
> >>
> >>     
> >
> >
> >       
> >
> >   
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

     

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist