Searching \ for '[PIC] 16F88 EE Corruption?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: '16F88 EE Corruption?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 16F88 EE Corruption?'
2009\09\30@025049 by David Duffy (AVD)

flavicon
face
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
___________________________________________

2009\09\30@034055 by Richard Prosser

picon face
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_OUTdavidTakeThisOuTspamaudiovisualdevices.com.au>:
{Quote hidden}

>

2009\09\30@043950 by Clint Sharp

picon face
In message <.....d02e69350909300040k4f2b267dwb82f1bf9c914cb4KILLspamspam@spam@mail.gmail.com>,
Richard Prosser <rhprosserspamKILLspamgmail.com> 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

2009\09\30@045010 by Bob Axtell

face picon face
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

2009\09\30@052631 by David Duffy (AVD)

flavicon
face
Bob Axtell wrote:
{Quote hidden}

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
___________________________________________

2009\09\30@073808 by Isaac Marino Bavaresco

flavicon
face
Bob Axtell escreveu:
{Quote hidden}

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/

2009\09\30@075912 by olin piclist
face picon face
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.

2009\09\30@090025 by Ariel Rocholl

flavicon
face
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 <.....engineerKILLspamspam.....cotse.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

2009\09\30@101258 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
{Quote hidden}

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/

2009\09\30@114722 by Bob Axtell

face picon face

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}

> -

2009\09\30@125015 by speff

picon face
Quoting Bob Axtell <engineerspamspam_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}

>> --

2009\09\30@164421 by David Duffy (AVD)

flavicon
face
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
___________________________________________


'[PIC] 16F88 EE Corruption?'
2009\10\04@100406 by Sean Breheny
face picon face
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 <KILLspamengineerKILLspamspamcotse.net> wrote:
{Quote hidden}

> -

2009\10\05@105812 by Bob Axtell

face picon face
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

2009\10\09@104835 by alan smith

picon face
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 <RemoveMEengineerTakeThisOuTspamcotse.net> wrote:

{Quote hidden}

> -

2009\10\09@152807 by Barry Gershenfeld

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

2009\10\09@155608 by alan smith

picon face
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 <gbarry42EraseMEspam.....gmail.com> wrote:

{Quote hidden}

> -

2009\10\09@215625 by Bob Axtell

face picon face
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}

>> --

2009\10\12@104847 by alan smith

picon face
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 <engineerSTOPspamspamspam_OUTcotse.net> wrote:

{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...