Searching \ for '[PIC] 16F parts flash being corrupted in power cyc' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/memory.htm?key=flash
Search entire site for: '16F parts flash being corrupted in power cyc'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 16F parts flash being corrupted in power cyc'
2006\07\28@164607 by Gerry Duprey

flavicon
face
Howdy,

I've been having problems lately with some of my battery operated products
where the flash in the PIC goes "bad" either during a power up or power down.
 This seems to be biting me especially badly on a project using a 16LF87 part.

Since the power supply is batteries, there are no real surges/spikes/dirty
power issues.  And all the PICs have at bypass cap on them for locally
generated noise (a small one -- .1uf and a larger 100uf).

It happens sporadically, but often enough to be a bother in prototyping and
understandably unacceptable in a product.

The 16LF87 is running on 4.5 volts (which is fine, the LF runs from 2.0 on
up), using it's internal 8Mhz oscillator.  The MCLR pin is disabled (so I can
use the pin as an input), so there are basically 16 I/O pins and power.  There
is nothing of any consequence (current wise - 20ma or so max) being switched
on or off by the pic and nothing else consuming power of the batteries.

I suspect it's a low volt condition during power down when things aren't
working right.  I have the powerup timer enabled, so I suspect everything is
pretty stable when starting up.  I wanted to enable the brown out detector,
but it has a fixed voltage setting that is around 4.3 volts, making it pretty
useless for a LF part that runs at anywhere from 4.0 to 4.5 volts (depending
on the charge).

I'm hoping others have come across this can have some suggestions.  I've got
to imagine I'm doing something wrong or there would be a huge outcry about
these parts corrupting themselves.

Thanks,

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org

2006\07\28@170620 by Bob Axtell

face picon face
Gerry Duprey wrote:
> Howdy,
>
> I've been having problems lately with some of my battery operated products
> where the flash in the PIC goes "bad" either during a power up or power down.
>  
Can you clarify? Do you mean that the PIC cannot be programmed
thereafter? Or do you mean that the EEROM
can't be read internally during the power down state? Or do you mean
that the data is wrong during that
time?

During product  tests I've seen and can explain some things, but I need
to know everything that's happening.

{Quote hidden}

I don't think the LF87 can run at 8Mhz at 2V... can it?

> I suspect it's a low volt condition during power down when things aren't
> working right.
Probably. use an external detector to execute a momentary, controlled
"short" across VDD and GND
as it powers down.

{Quote hidden}

I'd use the WDT, since if it begins to execute in the wrong place, it
will reset the processor.

There's a trick I do to verify operation- I call to various parts of the
CODE array and test what I get
back. I also perform a WDT reset (clrwdt) just before I return. If I
don't return, the WDT will reset.
I also perform a set of these at power up, so that the processor won't
execute any important code
until the power supply is stable.


--Bob

2006\07\28@170759 by John Temples

flavicon
face
On Fri, 28 Jul 2006, Gerry Duprey wrote:

> I've been having problems lately with some of my battery operated products
> where the flash in the PIC goes "bad" either during a power up or power down.

Do you have a bootloader, or other write-to-flash code?

--
John W. Temples, III

2006\07\28@215032 by Gerry Duprey

flavicon
face
Howdy,

> Can you clarify? Do you mean that the PIC cannot be programmed
> thereafter? Or do you mean that the EEROM
> can't be read internally during the power down state? Or do you mean
> that the data is wrong during that
> time?

The chip appears physically fine and can be reflashed and then put back into
service.  It's just the contents of the flash seem to get nicked  during power
cycles and stay nicked until reflashed   Like the flash contents got corrupted.

>>The 16LF87 is running on 4.5 volts (which is fine, the LF runs from 2.0 on
>
> I don't think the LF87 can run at 8Mhz at 2V... can it?

Nope -- but I'm not running at the the low end -- I'm running closer to 4.0 to
4.5 which is well inside the safe zone for the part/frequency (after 3V, you
can run at 10Mhz).

> I'd use the WDT, since if it begins to execute in the wrong place, it
> will reset the processor.

In fact, I do have a WDT running on some of the parts and while it does help
in that things don't run wacky for too long, it doesn't seem to impact the
flash being dinged.

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org

2006\07\28@215111 by Gerry Duprey

flavicon
face
Howdy,

> Do you have a bootloader, or other write-to-flash code?

On my 16F877A projects yes, but not using one for the 16LF87 and 16LF88 projects.

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org

2006\07\29@024819 by Bob Axtell

face picon face
OK, good answers. My comments below.

Gerry Duprey wrote:
> Howdy,
>
>  
>> Can you clarify? Do you mean that the PIC cannot be programmed
>> thereafter? Or do you mean that the EEROM
>> can't be read internally during the power down state? Or do you mean
>> that the data is wrong during that
>> time?
>>    
>
> The chip appears physically fine and can be reflashed and then put back into
> service.  It's just the contents of the flash seem to get nicked  during power
> cycles and stay nicked until reflashed   Like the flash contents got corrupted.
>
>  
The nanowatt series does not "flash" as solidly as earlier parts, such
as the PIC16C devices. I believe this
is due to the device die size being squeezed down. Nevertheless, what I
tend to see are devices losing their
EEROM data, not their CODE data. The two are written differently; the
EEROM frequently, the CODE is
infrequent.

I am skeptical of the device losing CODE data simply by power cycling, I
have never seen that. I think you need
to look at the possibility of:

1. The LVP pin trying to make the device go into programming mode. Make
sure that the LVP pin is held down
with a 10K resistor when powering up. I'll bet if you scope the pin
closely you'll find this to be the problem.

2. The MCLR pin receiving spikes above VDD.  Are you using this pin as
an input? If so, make sure this is
clamped at VDD, no matter how low it goes.


I don't think it applies here, but the Nanowatt EEROM data drops bits
frequently and must be refreshed. I accomplish
this by writing a variable in EEROM space three times (for best 2 of 3,
OK) or five times (best 3 of 5, IDEAL)
and if a byte is seen as incorrect, I rewrite all variable copies. I am
at a point where I don't even use the EEPROM
if the variable simply MUST be reliable. Microchip's I2C and SPI EEROM
devices do NOT have this problem...
go figure.


<respectful snip>


--Bob

2006\07\29@062359 by Mike Harrison

flavicon
face
On Fri, 28 Jul 2006 21:50:33 -0400, you wrote:

>Howdy,
>
>> Can you clarify? Do you mean that the PIC cannot be programmed
>> thereafter? Or do you mean that the EEROM
>> can't be read internally during the power down state? Or do you mean
>> that the data is wrong during that
>> time?
>
>The chip appears physically fine and can be reflashed and then put back into
>service.  It's just the contents of the flash seem to get nicked  during power
>cycles and stay nicked until reflashed   Like the flash contents got corrupted.

I missed the start of this thread - have you positively confirmed that the flash is definitely
getting corrupted, i.e. by verifying it afterwards?

The reason I ask is that an un-initalised variable problem could produce the same symptoms of
'application suddenly stops working but reprogramming fixes it'




2006\07\29@095717 by Maarten Hofman

face picon face
>
> > Can you clarify? Do you mean that the PIC cannot be programmed
> > thereafter? Or do you mean that the EEROM
> > can't be read internally during the power down state? Or do you mean
> > that the data is wrong during that
> > time?
>
> The chip appears physically fine and can be reflashed and then put back
> into
> service.  It's just the contents of the flash seem to get nicked  during
> power
> cycles and stay nicked until reflashed   Like the flash contents got
> corrupted.


What percentage of the flash contents got corrupted? Was there a specific
pattern to the corruption?

My experience with these kinds of corruptions is that a programmer was used
that wasn't operating according to specifications, although I have not used
any LF parts myself, I did notice similar things happening with certain
16F628A chips. However, as said, I could always trace it back to a problem
with the programmer.

Greetings,
Maarten Hofman.

2006\07\29@102538 by Bob Axtell

face picon face
Maarten Hofman wrote:

<I snipped a lot so Russell (and others) don't have to wade thru a lot
of unneeded space.>

It just dawned on me that you are using ICSP to program the device. I
noticed that when
a strong RF field was present near the PIC, the MCLR pin needed a small
cap (100pF) to
stop being flooded by the RF. I did it by using a jumper that sat on my
2mm 5-pin ICSP
jack with a mounted 100pF cap.

Do you use an RF xmittr in the project?

--Bob

2006\07\29@102723 by Gerry Duprey

flavicon
face
Howdy,

> 1. The LVP pin trying to make the device go into programming mode. Make
> sure that the LVP pin is held down
> with a 10K resistor when powering up. I'll bet if you scope the pin
> closely you'll find this to be the problem.

PS is only 5V.  All pins are configed for digital I/O and the LVP programming
is disabled via config fuses.

> 2. The MCLR pin receiving spikes above VDD.  Are you using this pin as
> an input? If so, make sure this is
> clamped at VDD, no matter how low it goes.

MCLR is disabled, so the pin is Input only and is tied either to Vss or Vdd.
It's a single voltage supply, so I'm pretty sure it's not getting out of spec.

> I don't think it applies here, but the Nanowatt EEROM data drops bits
> frequently and must be refreshed. I accomplish
> this by writing a variable in EEROM space three times (for best 2 of 3,

Well, I suppose this could be a problem.  EEPROM contents are not checked when
read (normal parametric data is upon reception before installation).  I do
have an EEPROM signature at the start of EEPROM that I check and if invalid, I
don't use it.  But that wouldn't stop some bits later on getting bonked.

I do insure the EEADDR is not left pointing at any of my EEPROM data after a
read or write and I know the corruption events are not related to EEPROM read
or write (read is only at power up, write is by command and very deliberate
and infrequent).

Perhaps a checksum at the end might be a good idea.

When you say you write it 3 or 5 five times -- are you writing and then
reading back to see if it matched or just writing repeatedly?  If the later do
you re-write each byte or do you write them all, then go back to the start and
write them all again?

It certainly is possible and it would explain reprogramming as a fix as that
clears EEPROM.  I can live with bad EEPROM (this is not a crucial system and
it has a perfectly valid default config that gets installed if there is no
EEPROM data detected), so my goals would be to identify if this is really
EEPROM related and if so, put in multiple writes and some sort of simple check
sum after the complete read.

I'll report back on what I find.

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org

2006\07\29@103142 by Gerry Duprey

flavicon
face
Howdy,

> I missed the start of this thread - have you positively confirmed that the flash is definitely
> getting corrupted, i.e. by verifying it afterwards?

Surprisingly (to me), I've not done a verify cycle!  I'll do that next time
this happens and see.  I also have the EEPROM track to look into now too (per
the earlier note).

> The reason I ask is that an un-initalised variable problem could produce the same symptoms of
> 'application suddenly stops working but reprogramming fixes it'

While it certainly could be an uninitialized pointer, the things that make me
think it's more hardware is that while power is applied, nothing goes wrong.
The chip can be up and running for weeks without a problem.  The event the is
coincident with corrupts is power cycling.  So while I'm not saying I don't
have such a bug (I'd never suggest I don't have bugs :-), I think this is more
related to an event than a bug (or at least mostly so).

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org

2006\07\29@103453 by Gerry Duprey

flavicon
face
Howdy,

> What percentage of the flash contents got corrupted? Was there a specific
> pattern to the corruption?

Not sure -- I'm going to run a verify pass on the flash before reprogramming
next time this happens.

> My experience with these kinds of corruptions is that a programmer was used
> that wasn't operating according to specifications, although I have not used
> any LF parts myself, I did notice similar things happening with certain
> 16F628A chips. However, as said, I could always trace it back to a problem
> with the programmer.

Well, I'm currently using the EasyProg programmer which programs and then
tests/verifys at both 4.5 and 5.5 volts.  I used to use a PicStart+ until 1)
its speed drove me mildly crazy and 2) it croaked.  I had the same problem
with the same relative frequency with it.  That doesn't rule out a programmer
related issue, but I'm hoping to consider that a little later is nothing else
shows.

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org

2006\07\29@103644 by Gerry Duprey

flavicon
face
Howdy,

> It just dawned on me that you are using ICSP to program the device. I
> noticed that when
> a strong RF field was present near the PIC, the MCLR pin needed a small
> cap (100pF) to
> stop being flooded by the RF. I did it by using a jumper that sat on my
> 2mm 5-pin ICSP
> jack with a mounted 100pF cap.

Hmmm..  Nothing RF or even running at really RF speeds outside the chip (using
the internal oscillator, so not even an external xtal).  MCLR function is
disabled via config fuses.  I use a standalone programmer -- no ICSP yet.

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org

2006\07\29@105424 by Bob Axtell

face picon face
Gerry Duprey wrote:
> Howdy,
>
>  
>> 1. The LVP pin trying to make the device go into programming mode. Make
>> sure that the LVP pin is held down
>> with a 10K resistor when powering up. I'll bet if you scope the pin
>> closely you'll find this to be the problem.
>>    
>
> PS is only 5V.  All pins are configed for digital I/O and the LVP programming
> is disabled via config fuses.
>  
er.. the config fuse route is not effective in stopping the LVP pin from
causing trouble. Lost a lot of hours
chasing that one a coupla times before.
{Quote hidden}

When I write, I write all 5 immediately (right next to each other) then
i immediately verify them; if they did not
write, I keep writing until they verify. If later I have a single byte
in error during read, I overwrite all 5 again,
repeating until they verify. If I have a defective chip, I'd rather it
hang in a loop here than screw up when the
client needs it to work.

In the past I used checksums too, but  they only tell you that you have
bad data, they don't provide a fix. Best
3 of 5 is a FIX.

AND... you have to verify your writes every time. I even verify my
writes when using a bootloader to install
new firmware. BTW, the usual reason self-writes fail is that an
interrupt happened right in the middle of a write cycle.

> It certainly is possible and it would explain reprogramming as a fix as that
> clears EEPROM.  I can live with bad EEPROM (this is not a crucial system and
> it has a perfectly valid default config that gets installed if there is no
> EEPROM data detected), so my goals would be to identify if this is really
> EEPROM related and if so, put in multiple writes and some sort of simple check
> sum after the complete read.
>
> I'll report back on what I find.
>  
Yes, please do.

- - -

Microchip needs to fix this annoying EEROM array problem for the
nanowatt series. It forces me to simply not
use the EEROM at all. I stick copyright info into it and never use it again.

--Bob

> Gerry
>  

2006\07\29@110342 by Mike Harrison

flavicon
face
On Sat, 29 Jul 2006 10:31:43 -0400, you wrote:

>Howdy,
>
>> I missed the start of this thread - have you positively confirmed that the flash is definitely
>> getting corrupted, i.e. by verifying it afterwards?
>
>Surprisingly (to me), I've not done a verify cycle!  I'll do that next time
>this happens and see.  I also have the EEPROM track to look into now too (per
>the earlier note).
>
>> The reason I ask is that an un-initalised variable problem could produce the same symptoms of
>> 'application suddenly stops working but reprogramming fixes it'
>
>While it certainly could be an uninitialized pointer, the things that make me
>think it's more hardware is that while power is applied, nothing goes wrong.

>The chip can be up and running for weeks without a problem.  The event the is
>coincident with corrupts is power cycling.  

..which is exactly what you would see if something was relying on an uninitialised RAM value,
although you might expect behaviour to be a bit more random than ' always working' followed by
'always not working'.




'[PIC] 16F parts flash being corrupted in power cyc'
2006\08\03@205855 by GK13
picon face

Most likely you are having brown out problem. Try enabling brown out reset.
PIC needs some minimum voltage to support 8MHz operation. It seems you have
100uF capacitor on Vdd. During power down situation, it may take some time
for it to discharge fully. This may create a situation where PIC is powered
with a Vdd that is outside the V/f spec. If you violate the V/f spec then
you cannot rely on proper code operation. If instruction read from the Flash
gets corrupted then you may see the problem you are describing. i.e. EEPROM
write function is interpreted as Flash write (just one RAM bit gor
corrupted). The BOR circuit is a tool to protect against violation of V/f
spec.

Enable the on-chip BOR circuit and test it. If it fixes the problem then it
was related to V/f spec violation during power up/ down situation.

Hope this helps
--
View this message in context: www.nabble.com/-PIC--16F-parts-flash-being-corrupted-in-power-cycles-tf2017533.html#a5643103
Sent from the MicroControllers - PIC forum at Nabble.com.

2006\08\12@164037 by Wouter van Ooijen

face picon face
> In fact, I do have a WDT running on some of the parts and
> while it does help
> in that things don't run wacky for too long, it doesn't seem
> to impact the
> flash being dinged.

1. do you use a brownout reset chip?
2. when you program the chip, is the Vcc within spec?
3. when you program the chip, do you verify at the Vcc extremes (==
production progamming in uChip speak)?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\08\14@201523 by GK13

picon face


> Do you have a bootloader, or other write-to-flash code?

On my 16F877A projects yes, but not using one for the 16LF87 and 16LF88
projects.


> The EEPROM write code can cause same issue. The one bit determines Flash
> access or EEPROM access. Did you test it with BOR enabled.

--
View this message in context: www.nabble.com/-PIC--16F-parts-flash-being-corrupted-in-power-cycles-tf2017533.html#a5806691
Sent from the MicroControllers - PIC forum at Nabble.com.

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