Searching \ for '[PIC] Speaking of EEPROM...' 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/memory.htm?key=eeprom
Search entire site for: 'Speaking of EEPROM...'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Speaking of EEPROM...'
2005\09\08@033711 by PicDude

flavicon
face
Had a problem recently where the EEPROM data on a PIC got corrupted during
operation.  I feel strongly that a power-surge/issue caused this.  Is this
really possible?  Or are there other conditions that can cause this?

BTW, here's why I feel that power caused it... the PIC stores counts of events
that occur periodically.  Each new data point is higher in value than the
previous one.  The EEPROM area is virtually divided into multiple groups, and
the groups are written to sort of like a circular buffer.  When writing a
group, each byte is written and then a checksum is written in the appropriate
location for that group.  After the last group is written, the first group is
re-used.  There are something like 20 groups of 4 bytes each.  If power is
switched off and back on, all EEPROM data is scanned as groups for valid data
(using the checksum) and the highest valid value is where the counting
re-starts for future events.  A loss of 1 occassionally due to power being
switched off during a write is okay.

This has been running successfully for some weeks, but when the EEPROM got
corrupted, there was a lot else on that power line, being switched on an off.  
And all of this occuring on a breadboard with a pretty crappy old AT
power-supply that can't regulate 5V properly to save it's life.  It varies
from 4.6V to 5.1V regularly depending on load.  As soon as I saw that data
get screwy (based on display output), I read-back the contents of the EEPROM,
and all locations were screwed up.  And the time between the noticed
corruption and the read-back was small enough to allow only 1 or 2 events to
occur.  The remaining data groups should've been valid.

Any idea what could cause this, and more what else I should be doing to
protect against this in the future?

Cheers,
-Neil.


2005\09\08@043048 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu]
>Sent: 08 September 2005 08:44
>To: piclistspamKILLspammit.edu
>Subject: [PIC] Speaking of EEPROM...
>
>
>Any idea what could cause this, and more what else I should be
>doing to
>protect against this in the future?

Did you have a programmer/debugger connected that could have issued an spurious erase command?

By the way, those old AT supplies often need a minimum load to regulate properly.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\09\08@051229 by Chen Xiao Fan

face
flavicon
face
Which PIC are you using? The recent dsPICs have some problems with
EEPROM. I think this may not be the case for you but you can still
check the errata.

Eg: From dsPIC30F4011/4012 errata (can not copy/paste from datasheet?!?!)
"The most significant bit of every fourth byte in data EEPROM may be
corrupted on any write operation. This write corruption may occur
while using either ProMate, MPLAB ICD2 or Run-Time Self-Programming
(RTSP)"

Regards,
Xiaofan

-----Original Message-----
From: PicDude [.....picdude2KILLspamspam.....narwani.org]
Sent: Thursday, September 08, 2005 3:44 PM
To: EraseMEpiclistspam_OUTspamTakeThisOuTmit.edu
Subject: [PIC] Speaking of EEPROM...


Had a problem recently where the EEPROM data on a PIC got corrupted during
operation.  I feel strongly that a power-surge/issue caused this.  Is this
really possible?  Or are there other conditions that can cause this?

Cheers,
-Neil.

2005\09\08@084721 by Bob Axtell

face picon face
PicDude wrote:

>Had a problem recently where the EEPROM data on a PIC got corrupted during
>operation.  I feel strongly that a power-surge/issue caused this.  Is this
>really possible?  Or are there other conditions that can cause this?
>
>BTW, here's why I feel that power caused it... the PIC stores counts of events
>that occur periodically.  Each new data point is higher in value than the
>previous one.  The EEPROM area is virtually divided into multiple groups, and
>the groups are written to sort of like a circular buffer.  When writing a
>group, each byte is written and then a checksum is written in the appropriate
>location for that group.  After the last group is written, the first group is
>re-used.  There are something like 20 groups of 4 bytes each.  If power is
>switched off and back on, all EEPROM data is scanned as groups for valid data
>(using the checksum) and the highest valid value is where the counting
>re-starts for future events.  A loss of 1 occassionally due to power being
>switched off during a write is okay.
>
>  
>
This has come up before on the list. I did a consulting job on this and
here is what I
decided:

1. This problem is unique to the newer PIC's, and was not noticed with
PIC16C??? devices.
The problem exists on other EEPROMs built from other vendors, including
ATMEL and
others, as well.

2. It seems that there is now a requirement to periodically refresh the
EEPROM. Microchip
recommends it  but the reason was never clear. Their method takes too
much code space
to implement.

3. The best way to solve this seems to be  to write the code so that
data was written in triplicate,
and when read back, use the "best two of three" method to decide what
data to use. When
writing, write all three in ONE PASS, then read them back to make sure
all three are written.

This solved the problem for my client and hasn't arisen since.

--Bob

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
attachspamspam_OUTengineer.cotse.net .
1-866-263-5745 USA/Canada
http://beam.to/azengineer

2005\09\08@102602 by PicDude

flavicon
face
> Did you have a programmer/debugger connected that could have issued an
> spurious erase command?

Nope.


> By the way, those old AT supplies often need a minimum load to regulate
> properly.

Yep.  I do have a min load on it.  Problem is that after running for some
time, the voltage level drops.  Also, the voltage drops when there is a load
of about 1A or so on it.

Chees,
-Neil.


2005\09\08@102808 by PicDude

flavicon
face
On Thursday 08 September 2005 04:12 am, Chen Xiao Fan scribbled:
> Which PIC are you using? The recent dsPICs have some problems with
> EEPROM. I think this may not be the case for you but you can still
> check the errata.

This was a 16F628.  In the archives I found a thread re: the 16F628A being
more susceptible to noise than the 16F628, but even if it were either of
these, I don't think noise should allow the EEPROM to get corrupted.

Cheers,
-Neil.


{Quote hidden}

2005\09\08@111258 by PicDude

flavicon
face
On Thursday 08 September 2005 07:47 am, Bob Axtell scribbled:
> This has come up before on the list. I did a consulting job on this and
> here is what I
> decided:
>
> 1. This problem is unique to the newer PIC's, and was not noticed with
> PIC16C??? devices.
> The problem exists on other EEPROMs built from other vendors, including
> ATMEL and
> others, as well.

Since you reference "16C...", I assume newer includes the flash devices such
as the 16F628 in this case?


> 2. It seems that there is now a requirement to periodically refresh the
> EEPROM. Microchip
> recommends it  but the reason was never clear. Their method takes too
> much code space
> to implement.

Ooohhh... that sucks.  I was really really trying to optimize the "system" so
that I don't overrun the min write cycles spec, and have just barely been
able to do so.  Refreshes would put me over that amount.  This also brings up
haunting memories of "CAS before RAS" dram refreshing.  <Shudder>.

Do you know the Microchip document that talks about this?  I'm searching their
site now but not coming up with anything relevant.  I'd also like to know is
how periodic is periodic.  


> 3. The best way to solve this seems to be  to write the code so that
> data was written in triplicate,
> and when read back, use the "best two of three" method to decide what
> data to use. When
> writing, write all three in ONE PASS, then read them back to make sure
> all three are written.

In my case though, it appeared that *all* data was corrupted, which I'm
guessing would not be helped by triplicating.  BTW, by "one pass" you mean to
do nothing else between writes of a single dataset?  I have too much else
going on, so I write and set a flag that one byte is written, then go do
other things.  The main code loop sees that other bytes are waiting to be
written and keeps checking the flags.  When a write is complete, it sets up
the next write, etc.


> This solved the problem for my client and hasn't arisen since.
>
> --Bob


I may have to re-engineer the "system", but I'm guessing my solution also lies
with something like this.  I'd really really really like to avoid using an
external EEPROM for space reasons, and I'm sure I don't have enough free
pins.  If I did, I could've even used both the internal and an external
EEPROM and cross-check -- sort of like an EEPROM RAID system! :-)

Cheers,
-Neil.



2005\09\08@113141 by Stef Mientki

flavicon
face

>Ooohhh... that sucks.  I was really really trying to optimize the "system" so
>that I don't overrun the min write cycles spec, and have just barely been
>able to do so.  Refreshes would put me over that amount.  This also brings up
>haunting memories of "CAS before RAS" dram refreshing.  <Shudder>.
>
>Do you know the Microchip document that talks about this?  I'm searching their
>site now but not coming up with anything relevant.  I'd also like to know is
>how periodic is periodic.  
>
>  
>
Sometime ago there was a discussion, and also a reaction from mc,
I wrote the most interesting parts down here:

  http://oase.uci.kun.nl/~mientki/pic/libs_hw/eeprom_problems.html

Stef Mientki

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

2005\09\08@113455 by Jan-Erik Soderholm

face picon face
Bob Axtell wrote :

> > 2. It seems that there is now a requirement to periodically
> > refresh the EEPROM. Microchip recommends it but the
> > reason was never clear. Their method takes too
> > much code space  to implement.
>

And PicDude commented :

>  Refreshes would put me over that amount...

Is this some *other* EEPROM-refresh then
the already well-known one ?

And if so, any pointers ?

Regards,
Jan-Erik.



2005\09\09@143809 by PicDude

flavicon
face
Stef,

This is both informative, thanks, and disturbing.  It leaves a lot of
questions open still.  But the basic ones are:
- Since refreshing is re-writing the same data, does it count as a second
write (effectively consuming one count of the endurance)?
- How often does this need to be refreshed?  Since my application can be off
for long periods, does this affect the EEPROM?  Or is the refresh period a
function of on/run time?
- I can't find anything on this on Microchip's website.  Is there a link to a
doc discussing this?

On another branch, there was mention that this affects Atmels and other
processors.  But what about serial EEPROMs?  Are these subject to the same
corruption issues?

Cheers,
-Neil.




On Thursday 08 September 2005 10:31 am, Stef Mientki scribbled:
{Quote hidden}

2005\09\09@144501 by James Newton, Host

face picon face
> Sometime ago there was a discussion, and also a reaction from
> mc, I wrote the most interesting parts down here:
>
>    oase.uci.kun.nl/~mientki/pic/libs_hw/eeprom_problems.html
>
> Stef Mientki

I took the liberty of copying that to
http://www.piclist.com/techref/mem/eeprom/corruption.htm along side other
information from David VanHorn.

---
James Newton: PICList webmaster/Admin
RemoveMEjamesnewtonTakeThisOuTspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2005\09\09@162407 by Jan-Erik Soderholm

face picon face
PicDude wrote :

> - Since refreshing is re-writing the same data, does it count
> as a second write (effectively consuming one count of the
endurance)?

Probably, I don't think the endurance depends on the data
actualy *changing* (or not) between writes, since the cell
is erased anyway in the same operation.

> - How often does this need to be refreshed?

The actual data sheet params was mentioned in another
post in this thread, or maybe on Stef's page...

> Since my application can be off
> for long periods, does this affect the EEPROM?
> Or is the refresh period a  function of on/run time?

The refresh period is a function of the number-of-writes-
to-*other*-cells.

> - I can't find anything on this on Microchip's website.  Is
> there a link to a  doc discussing this?

It's in most (all ?) data sheets. At least for devices
with EEPROM... :-)

>
> On another branch, there was mention that this affects Atmels
> and other processors.  But what about serial EEPROMs?
> Are these subject to the same corruption issues?

If so, it should be in the data sheet, just as for the PICs, no ?

Jan-Erik.



2005\09\09@164857 by Paul Hutchinson

picon face
> -----Original Message-----
> From: spamBeGonepiclist-bouncesspamBeGonespammit.edu On Behalf Of PicDude
> Sent: Friday, September 09, 2005 2:45 PM
>
> Stef,
>
> This is both informative, thanks, and disturbing.  It leaves a lot of
> questions open still.  But the basic ones are:
<snip>
> doc discussing this?
>
> On another branch, there was mention that this affects Atmels and other
> processors.  But what about serial EEPROMs?  Are these subject to
> the same corruption issues?

This problem does _not_ occur in serial EEPROM'S, well at least the ones
I've read the data sheets for, which includes most of the Microchip 24
series parts.

Paul Hutch

>
> Cheers,
> -Neil.
>

2005\09\10@104517 by Gerhard Fiedler

picon face
Jan-Erik Soderholm wrote:

>> - How often does this need to be refreshed?
>
> The actual data sheet params was mentioned in another post in this
> thread, or maybe on Stef's page...

>> - I can't find anything on this on Microchip's website.  Is there a link
>> to a  doc discussing this?
>
> It's in most (all ?) data sheets. At least for devices with EEPROM...

I looked up two datasheets of PICs with EEPROM. They don't all provide this
information.
In one (18F2431) they list D120 as "Byte Endurance at +85 °C" (100k) and
D124 as "Number of Total Erase/Write Cycles before Refresh" (1M). This
seems to indicate that you can write to any single cell up to 100k times
(over the lifetime of the chip) and that you have to do a data refresh
after 1M total erase/write cycles on the EEPROM at a whole (other
locations). This is essentially what Bob is talking about on that page.
In the other (18F6680) they do not list D124 at all, only D120 as "Cell
Endurance at +85 °C" with 100k -- even though they refer to D124 in the
EEPROM section of the description. But that description looks a lot like
copy and paste (like some others :).

So it seems that D124 (that's the crucial piece of data here) is not
present in all datasheets of PICs with EEPROMs -- whatever that means. If
you write a lot to some cells and infrequently to others, you could go safe
and consider a typical minimum value for D124, even if it's not listed. And
I'm not sure how that applies or not to serial EEPROMs.

Does Microchip use different technology for the different EEPROMs in
different PIC and serial EEPROM models? If not, one could assume that the
D124 parameter applies, whether it's listed in the datasheet or not -- for
both PICs and serial EEPROMs.

Gerhard

2005\09\10@111731 by PicDude

flavicon
face
On Saturday 10 September 2005 09:45 am, Gerhard Fiedler scribbled:
> I looked up two datasheets of PICs with EEPROM. They don't all provide this
> information.

My finding too.


> ...
> Does Microchip use different technology for the different EEPROMs in
> different PIC and serial EEPROM models? If not, one could assume that the
> D124 parameter applies, whether it's listed in the datasheet or not -- for
> both PICs and serial EEPROMs.

I'm pretty sure of it.  IIRC (don't have any datasheets at this machine), the
16F628A for example, has 10x the endurance of the 16F87x.  Also, yesterday I
found on the 16F818 datasheet a "FREE" bit on EECON1.  Still trying to get
info on the full use of it (since they don't use it or clear it for their
EEPROM write example, nor does the mid-range manual (which should apply to
the 16F818) make any mention of it), but it at least indicates that the
EEPROM mechanisms are different from PIC to PIC, if not the technology.

Cheers,
-Neil.


2005\09\12@021505 by Jim Robertson

flavicon
face


>Also, yesterday I
>found on the 16F818 datasheet a "FREE" bit on EECON1.  Still trying to get
>info on the full use of it (since they don't use it or clear it for their
>EEPROM write example, nor does the mid-range manual (which should apply to
>the 16F818) make any mention of it), but it at least indicates that the
>EEPROM mechanisms are different from PIC to PIC, if not the technology.
>
>Cheers,
>-Neil.

The FREE bit has nothing to do with the EEPROM memory. It is used to
control the ROW mode
erasing of  the flash program memory.  One only has to do a search for the
word "FREE" in the DS39598
data sheet to find where it is documented and how and when it is used.

Regards,

Jim Robertson
NEWFOUND ELECTRONICS



2005\09\12@132337 by PicDude

flavicon
face
Don't have the datasheet on this machine, but IIRC on the listing of bits in
the EECON1 byte, it was called "EEPROM forced row erase bit".  I think this
causes that confusion since if it were for program memory only, I would've
expected it to be called "FLASH forced row erase bit."

Cheers,
-Neil.


On Monday 12 September 2005 01:15 am, Jim Robertson scribbled:
> The FREE bit has nothing to do with the EEPROM memory. It is used to
> control the ROW mode
> erasing of  the flash program memory.  One only has to do a search for the
> word "FREE" in the DS39598
> data sheet to find where it is documented and how and when it is used.


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