Searching \ for '[PIC] Notice: PIC12F629 has same EEPROM errors as' 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: 'Notice: PIC12F629 has same EEPROM errors as'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Notice: PIC12F629 has same EEPROM errors as '
2006\10\19@140126 by Bob Axtell

face picon face
Thanks again, Alan Pierce!

I have been experienced incredible EEPROM unreliability with the 12F629.
I have spent days on it. It appears that chip revision 0xC of the PIC12F629
(12F675 I will test later) has the SAME problem as the PIC16F627,
PIC16F628, and PIC16F648, in that the CPU operation is NOT suspended
while the WR bit of EECON1 is true. Alan brought this to my attention, and
since the EEPROM engine for both is identical, testing for several hours
indicates
that seems to be the problem on this device as well!!

The result is that the WR bit may drop early if the CPU is running, and
will not
RELIABLY flash the byte (but sometimes will).

The only possible workaround is to force the CPU to halt during the WR
operation by means of  SLEEP followed by the EEIE interrupt  restarting
the CPU after WR has gone away.

This code WORKS:

; EEROM: write a byte in w @tmp, using SLEEP to solve CPU issue:
wreeerom:
   clrf    status
   bcf        pir1,EEIF    ;make sure it's lo
   bank1
   clrf    EECON1
   movwf     EEDATA
   movf    tmp,w      
   movwf     EEADR
   bcf        intcon,gie
   bsf        intcon,PEIE
   bsf        pie1,EEIE  
;         very critical section
   clrwdt
   bsf     EECON1,WREN
   movlw    h'55'
   movwf    EECON2
   movlw     h'AA'
   movwf     EECON2
   bsf        EECON1,WR
   SLEEP
   bcf     EECON1,WREN
;    end of critical section          
   bcf        intcon,PEIE
   bcf        pie1,EEIE  
   bsf        intcon,gie
   clrf      status      ;bank 0
   return

; this following code does NOT work reliably,
; taken from PIC12F629/675 manual...
; EEROM: write a byte in w @tmp
wreeerom:
   bank1
   clrf    EECON1
   movwf     EEDATA
   movf    tmp,w      
   movwf     EEADR
   bcf        intcon,gie
   clrwdt
 ;
   bsf     EECON1,WREN
   movlw    h'55'
   movwf    EECON2
   movlw     h'AA'
   movwf     EECON2
   bsf        EECON1,WR
;          
   btfsc   EECON1,WR
   goto  $-1
   bcf     EECON1,WREN
   bsf        intcon,gie
   clrf      status      ;bank 0
   return

Be advised. I'll test some more, I suspect it has a problem on the F675 as
well, before I tell Microchip.

--Bob

2006\10\19@143438 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu]
>Sent: 19 October 2006 19:01
>To: Microcontroller discussion list - Public.
>Subject: [PIC] Notice: PIC12F629 has same EEPROM errors as
>PIC`16F628 et al
>
>
>Thanks again, Alan Pierce!
>
>I have been experienced incredible EEPROM unreliability with
>the 12F629. I have spent days on it. It appears that chip
>revision 0xC of the PIC12F629 (12F675 I will test later) has
>the SAME problem as the PIC16F627, PIC16F628, and PIC16F648,
>in that the CPU operation is NOT suspended while the WR bit of
>EECON1 is true.

Bob,

Sorry if I haven't quite grasped this, but are you saying that some PICs do suspend the CPU during writes to the EEPROM?  I know the CPU is suspended when writing to Flash (on those PIC's that support self writes), but I have never encountered one that suspends when writing to EEPROM.  This behaviour would somewhat negate the advantage of using the EEIF interrupt wouldn't it?

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

2006\10\19@173336 by Tamas Rudnai

face picon face
In my interpretation it means that there is a problem with the WR that it
will be zeroed out internally before the actual write had been done. So when
the CPU put into sleep mode it does not occur. So as far as I concern the
sleep is just a workaround but I may completly wrong?

Tamas


On 19/10/06, Michael Rigby-Jones <Michael.Rigby-JonesspamKILLspambookham.com> wrote:
>
>
>
> >{Original Message removed}

2006\10\19@203402 by Bob Axtell

face picon face
Michael Rigby-Jones wrote:
{Quote hidden}

Take a look at the errata sheet for the PIC16F627/628/648. perhaps I
wrote a wrong explanation. All I know is that polling the WR  bit
doesn't seem to work, while
using the EEIF interrupt after a sleep works.

--Bob

{Quote hidden}

2006\10\19@203514 by Bob Axtell

face picon face
Tamas Rudnai wrote:
> In my interpretation it means that there is a problem with the WR that it
> will be zeroed out internally before the actual write had been done. So when
> the CPU put into sleep mode it does not occur. So as far as I concern the
> sleep is just a workaround but I may completly wrong?
>
> Tamas
>  

Yes, that's it.

--Bob
>
> On 19/10/06, Michael Rigby-Jones <Michael.Rigby-Jonesspamspam_OUTbookham.com> wrote:
>  
>>
>>    
>>> {Original Message removed}

2006\10\19@210436 by Andy Tuthill

picon face
Hi Bob,

I had a project recently with a 12F675 that I wanted to do 3 sequential
eeprom writes for settings data.  The plan was to let the eeprom interrupt
send the next data byte because the write should be complete at that time.  
What I found was that if I started another write cycle as soon as the WR bit
reset that I had problems and usually nothing ended up in eeprom.  As I
understand the data sheet the eeprom interrupt happens at the end of the
cycle so I should be free to start another write.  This works fine in other
chips.

In the end the work around I found was to rearrange the code to give the
chip loads of time before trying to write the next byte.  I never tried to
find out just what time threshold was required but I gave it massively
longer than the 5 ms I normally associate with a write cycle.

This may or may not be another aspect of what you are describing.  This does
tend to differ from the sleep option to a degree because I don't watch the
WR bit now while the sleep does.

Regards,
Andy

_________________________________________________________________
Add a Yahoo! contact to Windows Live Messenger for a chance to win a free
trip!
http://www.imagine-windowslive.com/minisites/yahoo/default.aspx?locale=en-us&hmtagline

2006\10\19@231328 by Bob Axtell

face picon face
Andy Tuthill wrote:
{Quote hidden}

Yes. Maybe what is happening is simply that using the WR bit simply
doesn't work, whereas the EEIF bit
does.

Yours is another possibility. Actually I thought of trying that, but I
knew that the flash time would be greatly
extended at 3V, so would cause a LOT of extra delay (I have to write 6
bytes). I ran some tests on another
PIC a while back at 3V and got o'scope readings of over 6mS, and 5V PICs
would flash in 3.5mS or so.

What is annoying me most is that these nanowatt EEPROM problems are
incredibly time consuming, and they
make me look like an idiot. These puppies also drop bits, so have to be
refreshed periodically. The PIC16C
devices didn't have the convenience of flash, but they certainly had a
solid, usable EEPROM array.

--Bob




> Regards,
> Andy
>
> _________________________________________________________________
> Add a Yahoo! contact to Windows Live Messenger for a chance to win a free
> trip!
> http://www.imagine-windowslive.com/minisites/yahoo/default.aspx?locale=en-us&hmtagline
>
>  

2006\10\20@031422 by Mircea Chiriciuc

picon face
Hi,

I have experienced similar problems with 16F627, but I couldn't
figure out the problem. Just noticed that sometimes, very random so
it seamed, the data does not get written to the EEPROM correctly. I
ended up writing the same value to 3 different locations and compare
the values from all 3 locations after reading, assuming that the 2
coincident values are the good one, because I had to fix "my bug" in
the product asap.
Thank you for clearing things up. I hope the 18F series do not have
the same problem....

My best regards to you all,
Mircea Chiriciuc


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.408 / Virus Database: 268.13.7/488 - Release Date: 10/19/2006


2006\10\20@034654 by Pearce, AB (Alan)

face picon face
>Thanks again, Alan Pierce!

Well, I cannot really take much credit, just happened to be glancing
through the errata sheet after downloading it, and happened to notice
the EEPROM problem similar to yours.

Still, I guess that is the way of "great" discoveries. ;)


2006\10\20@041120 by William Chops Westfield

face picon face
So what happens if you insert a simple delay loop after detecting
the WR bit change?  Or do double consecutive writes (shades of
EPROM programming algorithms...)

Has microchip said anything other than the 628/etc errata?

BillW

2006\10\20@062206 by Bob Axtell

face picon face
Pearce, AB (Alan) wrote:
>> Thanks again, Alan Pierce!
>>    
>
> Well, I cannot really take much credit, just happened to be glancing
> through the errata sheet after downloading it, and happened to notice
> the EEPROM problem similar to yours.
>
> Still, I guess that is the way of "great" discoveries. ;)
>
>
>  
You are my hero this week Alan. I dug all through the MC website, but it
never dawned on me that
a PIC12F and a PIC16F device might use the same, identical EEPROM
engine. Go figure!

These puppies now WORK, thanks to you. BTW, I don't have enough parts
for a thorough test, but
it appears that the PIC12F675 _AND_ the PIC12F629  have the same issue.

--Bob

2006\10\20@062830 by Bob Axtell

face picon face
William Chops Westfield wrote:
> So what happens if you insert a simple delay loop after detecting
> the WR bit change?  Or do double consecutive writes (shades of
> EPROM programming algorithms...)
>
> Has microchip said anything other than the 628/etc errata?
>
> BillW
>  
I haven't alerted them yet, I decided to percolate this until Monday. So
far, the PIC12F675s
seem to work reliably, too, but I don't have 50 devices to try like I
have with the F629...

What caught my attention was that the 16F627 and 12F629 have identical
EEPROM engines,
(same process, same bank switching, same bit names, etc) so I thought if
the  F627 was broken,
why not the F629 as well? This came from my knowledge that microchip  
reuses its peripheral
designs all over the place.

--Bob

2006\10\20@064042 by Pearce, AB (Alan)

face picon face
>These puppies now WORK, thanks to you. BTW, I don't have enough
>parts for a thorough test, but it appears that the PIC12F675 _
>AND_ the PIC12F629  have the same issue.

I guess a "nasty note" to the MChip errata department is in order then.
Point out that it was a chance discovery by someone else looking at
another chip errata, and these have the same problem.

2006\10\20@071738 by u12103129

face picon face
Bob Axtell wrote:

> I dug all through the MC website, but it never dawned
> on me that a PIC12F and a PIC16F device might use the same,
> identical EEPROM engine. Go figure!

First, not 12F in general, of course.

And note also that the 12F629/675 are *NOT* nanowatt devices,
as you wrote earlier in this thread.

The 12F683, on the other hand, is a nanowatt device.
And a realy nice "upgrade" from 12F629/675. Double
Flash, double RAM, an extra timer, 8 Mhz intosc and
all other nanowatt features.

Finaly, I have no idea if there are any differences in the
implementation of the EEPROM between 12F629/675 and 12F683.

Regards,
Jan-Erik.

2006\10\20@074540 by Bob Axtell

face picon face
u12103129 wrote:
{Quote hidden}

Well, my problem is solved, but I'll take a look at the 12F683 in the
future.
Thanks for the heads up.

Sorry about the nanowatt reference.

--Bob

2006\10\20@125548 by John Temples

flavicon
face
On Fri, 20 Oct 2006, Pearce, AB (Alan) wrote:

> I guess a "nasty note" to the MChip errata department is in order then.
> Point out that it was a chance discovery by someone else looking at
> another chip errata, and these have the same problem.

There apparently isn't an "errata department", as I learned by wasting
a half day discovering that the "I2C data recognized as address"
errata applies to parts other than just the ones it's documented for.
It seems that different app engineers are responsible for different
part families, and each app engineer is responsible for the
corresponding errata documents.  As such, errata documentation quality
varies.

--
John W. Temples, III

2006\10\20@144326 by Bob Axtell

face picon face
John Temples wrote:
> On Fri, 20 Oct 2006, Pearce, AB (Alan) wrote:
>
>  
>> I guess a "nasty note" to the MChip errata department is in order then.
>> Point out that it was a chance discovery by someone else looking at
>> another chip errata, and these have the same problem.
>>    
>
> There apparently isn't an "errata department", as I learned by wasting
> a half day discovering that the "I2C data recognized as address"
> errata applies to parts other than just the ones it's documented for.
> It seems that different app engineers are responsible for different
> part families, and each app engineer is responsible for the
> corresponding errata documents.  As such, errata documentation quality
> varies.
>
> --
> John W. Temples, III
>  
I will find out Monday or Tuesday.

In general, I am disgruntled that we have to dig these things out on our
own. Its cost me a pretty penny
to find these things out by grueling tests.

I am beginning to think that TI is looking better and better...

--Bob

2006\10\20@173314 by Jinx

face picon face
> In general, I am disgruntled that we have to dig these things out on
> our own. Its cost me a pretty penny to find these things out by
> grueling tests

Bob, I've wondered exactly what they do at Microchip *before*
releasing a chip. IANAchiptester but wouldn't they have some sort
of jig to put a device through its paces and give it a real workout ?
Sure, there are boundless combinations of interactions within the
chip, but that's their problem. Given that every PIC seems to have
teething troubles, after all these years you'd think that the silicon
designers might look closely at modifications they make to modules

Logically it sounds simple, maybe in practice it's not

2006\10\20@183540 by William Chops Westfield

face picon face

On Oct 20, 2006, at 2:27 PM, Jinx wrote:

> Given that every PIC seems to have
> teething troubles, after all these years you'd think that the silicon
> designers might look closely at modifications they make to modules
>
> Logically it sounds simple, maybe in practice it's not

Heh.  Testing, and especially test design, is HARD.

I've been playing with some Luminary Cortex M3 ARM chips, and their
errata makes microchip look good...

BillW

2006\10\20@200336 by Robert Rolf

picon face
Mircea Chiriciuc wrote:

> Hi,
>
> I have experienced similar problems with 16F627, but I couldn't
> figure out the problem. Just noticed that sometimes, very random so
> it seamed, the data does not get written to the EEPROM correctly. I
> ended up writing the same value to 3 different locations and compare
> the values from all 3 locations after reading, assuming that the 2
> coincident values are the good one, because I had to fix "my bug" in
> the product asap.

What about the simple test of verifying that you read back what you wrote to EEPROM,
perhaps after reading a dummy location to clear the registers?
Much simpler to impliment and space saving I would think.

2006\10\21@033055 by Mircea Chiriciuc

picon face
Hi Rolf,


>What about the simple test of verifying that you read back what you
>wrote to EEPROM,
>perhaps after reading a dummy location to clear the registers?
>Much simpler to impliment and space saving I would think.

I think it's more reliable this way. If one location fails in time,
there are 2 which still hold the data. The product was (and still is
in production) a counter for the working hours of an diesel engine
working in a harsh environment (cranes, digging machines, heavy
trucks). In this particular case I preferred spending one more hour
to write the code, rather than go to the machine and replace the
counter, or reprogram it on site. Never had a single problem reported
after this approach with storing data. The nasty part was hunting the
bug down to EEPROM write problem. Lots of hours (and money) spent
going to the test site which is 80km away and monitoring the device
to eliminate electronics failure (power, etc.).

My regards,

Mircea


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.408 / Virus Database: 268.13.9/490 - Release Date: 10/20/2006


2006\10\21@053101 by Bob Axtell

face picon face
Mircea Chiriciuc wrote:
{Quote hidden}

This latest problem was separate from the issue last year I found, where
the EEPROM array
was dropping bits. Microchip suggested an array refresh, but I do it
better (and easier, I think)
by performing a test of "best 2 of 3" (or "best 3 of 5" if highly
critical). I was implementing my
best 2 of 3 when I could not even write reliably on certain F629's.

This problem yesterday was that I could write, test, and write again,
without the data even being
stored. It turned out to be that the EECON1 WR bit could not be depended
on if polled; I used
the suggestion for the 16F627 where the device is put to sleep, and
awakened with the EEIF flag,
and that works perfectly, right on down to 3V or less.

Well, that why we get the big bucks...

--Bob



2006\10\21@142006 by William Chops Westfield

face picon face

On Oct 21, 2006, at 2:30 AM, Bob Axtell wrote:

> This latest problem was separate from the issue last year
> I found, where the EEPROM array was dropping bits.

Are you sure?  Were those also 3V writes using WR?  Perhaps at
higher voltages, WR is only slightly too soon, causing bits to
drop at a later date...

BillW

2006\10\21@144950 by Bob Axtell

face picon face
William Chops Westfield wrote:
> On Oct 21, 2006, at 2:30 AM, Bob Axtell wrote:
>
>  
>> This latest problem was separate from the issue last year
>> I found, where the EEPROM array was dropping bits.
>>    
>
> Are you sure?  Were those also 3V writes using WR?  Perhaps at
> higher voltages, WR is only slightly too soon, causing bits to
> drop at a later date...
>
> BillW
>  
Maye they are the same issue. But MC issued the advisory to rewrite the
whole array.

Whatever. I'm fixed now. writes properly down to less than 3V now
reliably (first pass).

--Bob

2006\10\21@184507 by Dwayne Reid

flavicon
face
At 12:49 PM 10/21/2006, Bob Axtell wrote:

>Whatever. I'm fixed now. writes properly down to less than 3V now
>reliably (first pass).

Quick question: are you using the watchdog prescaler?  In other
words, does the EEIF flag occur (during sleep) before the watchdog
times out, even with the prescale set to 1?

I'd also be interested in seeing just how long those particular PICs
are taking to do the write.  Would you have a few minutes to try
wiggling a port pin before and after going to sleep to get an
estimate of the write time?

Just curious . . .

dwayne

--
Dwayne Reid   <@spam@dwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 22 years of Engineering Innovation (1984 - 2006)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

2006\10\21@222137 by Bob Axtell

face picon face
Dwayne Reid wrote:
{Quote hidden}

On the 12F675 and 12F629, all I use is standard WDT timeout, i.e. 17 mS
approx. I issue a
clrwdt immediately before starting the EEPROM write. The write never
takes more than 8mS,
usually less.  But I ALWAYS use the WDT in normal operation. Using a WDT
stops other
critical issues.

OK, I will measure it for you. I have a setup at 3.3V or 5V (jumper),
but I am in the middle of
something right now. Is Sunday afternoon OK?.

--Bob

2006\10\23@044329 by Bob Axtell

face picon face
Dwayne Reid wrote:
{Quote hidden}

I measured 3 F629's; write time at 5V was 2.5ms to 3mS.
at 3.3V was 4.5ms to 5.5mS. Falls inside of the max value
Microchip provides in the datasheet.

--Bob

2006\10\23@102458 by Gerhard Fiedler

picon face
William ChopsWestfield wrote:

> On Oct 20, 2006, at 2:27 PM, Jinx wrote:
>
>> Given that every PIC seems to have teething troubles, after all these
>> years you'd think that the silicon designers might look closely at
>> modifications they make to modules
>>
>> Logically it sounds simple, maybe in practice it's not
>
> Heh.  Testing, and especially test design, is HARD.

OTOH, one would think that they have a pretty good test suite by now, after
so many devices. Many peripherals are similar or identical between devices,
so there's a lot of tests that can be shared or used slightly modified.

Gerhard

2006\10\23@102644 by alan smith

picon face
Do you have a local FAE that drops in every few weeks to discuss issues?  I'd think that bringing this up with them would be a pretty direct method to get this back to the factory.

Bob Axtell <KILLspamengineerKILLspamspamneomailbox.com> wrote:  John Temples wrote:
> On Fri, 20 Oct 2006, Pearce, AB (Alan) wrote:
>
>
>> I guess a "nasty note" to the MChip errata department is in order then.
>> Point out that it was a chance discovery by someone else looking at
>> another chip errata, and these have the same problem.
>>
>
> There apparently isn't an "errata department", as I learned by wasting
> a half day discovering that the "I2C data recognized as address"
> errata applies to parts other than just the ones it's documented for.
> It seems that different app engineers are responsible for different
> part families, and each app engineer is responsible for the
> corresponding errata documents. As such, errata documentation quality
> varies.
>
> --
> John W. Temples, III
>
I will find out Monday or Tuesday.

In general, I am disgruntled that we have to dig these things out on our
own. Its cost me a pretty penny
to find these things out by grueling tests.

I am beginning to think that TI is looking better and better...

--Bob

2006\10\24@111512 by Dwayne Reid

flavicon
face
At 02:43 AM 10/23/2006, Bob Axtell wrote:
>Dwayne Reid wrote:
> >
> > I'd also be interested in seeing just how long those particular PICs
> > are taking to do the write.  Would you have a few minutes to try
> > wiggling a port pin before and after going to sleep to get an
> > estimate of the write time?
> >
> > Just curious . . .
> >
> > dwayne
> >
>I measured 3 F629's; write time at 5V was 2.5ms to 3mS.
>at 3.3V was 4.5ms to 5.5mS. Falls inside of the max value
>Microchip provides in the datasheet.

Many thanks, Bob.  Well clear of the worst case (fastest) WDT
time-out period, then.  FWIW, I always figure quickest WDT time-out
to be about 9ms and ensure that it gets tickled quicker than that.

Yeah - I know the data sheet sez 18ms but I've seen it MUCH shorter
than that under temperature extremes.

dwayne

--
Dwayne Reid   <RemoveMEdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 22 years of Engineering Innovation (1984 - 2006)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

2006\10\24@160726 by Barry Gershenfeld

face picon face

>
>Yes. Maybe what is happening is simply that using the WR bit simply
>doesn't work, whereas the EEIF bit
>does.

Makes me wonder if the two bits really change at the same time.  If I had
this hardware in front of me I would try a loop that polls and stores the
state of the bits (in RAM).  Then peek at the results to see what
happened.  Kind of like a graph, but very quick and dirty.  Have to adjust
some delay in between samples so the event fits in RAM.

Another thought is that it takes some time to wake from sleep, and that
could affect your success rate (as opposed to the theory that the
sleep-int-wake method is actually correct).

I know it's all working now, but, well, we /are/ engineers and can't stop
wondering about it.

Anyway, good thread about another PIC quirk.  I shall mark it and save it.

Barry


2006\10\24@174646 by Gerhard Fiedler

picon face
Barry Gershenfeld wrote:

> Makes me wonder if the two bits really change at the same time.  If I had
> this hardware in front of me I would try a loop that polls and stores the
> state of the bits (in RAM).  Then peek at the results to see what
> happened.  Kind of like a graph, but very quick and dirty.  Have to adjust
> some delay in between samples so the event fits in RAM.

If you make it a circular buffer and stop when either one is set and the
other not or both are set for the first time (depending on what you want to
see), you don't really need any delay.

Another way of doing this is to poll them and store the content of a
high-res timer when the changes happen.

Gerhard

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