Forums

Flash code corruption on pic6f870

Started by Unknown February 27, 2005
I have about 20 units in the field using the PIC16f870. Some have been
in use for nearly 2 years without any problems but recently 2 units
have come back as faulty. They have the same symptons, the program
crashes during its interrupt routine, it doesn't return, it doeas
execute the first few instructions though I can tell how far it gets
before it crashes. After 15mS the watchdog resets and the cycle
repeats. There appears to be no hardware faults anywhere. Ive read the
data eeprom values and they are as expected, I can't read the code as
its protected. Low voltage programming is disabled and code protection
bits are set. The program does not have any routines for writing to
code memory. If I reprogram the chip with the same software it now
works faultlessly. Anyone got any ideas?

cbarn24050@aol.com wrote:
> I have about 20 units in the field using the PIC16f870. Some have been > in use for nearly 2 years without any problems but recently 2 units > have come back as faulty. They have the same symptons, the program > crashes during its interrupt routine, it doesn't return, it doeas > execute the first few instructions though I can tell how far it gets > before it crashes. After 15mS the watchdog resets and the cycle > repeats. There appears to be no hardware faults anywhere. Ive read the > data eeprom values and they are as expected, I can't read the code as > its protected. Low voltage programming is disabled and code protection > bits are set. The program does not have any routines for writing to > code memory. If I reprogram the chip with the same software it now > works faultlessly. Anyone got any ideas? >
Did they come from the same place / same installation? That may point to a common failure mode. It's also helpful to "unwind" during a reset routine: check the checksum (or CRC if you can afford it) of the init code itself, and of interrupt routines before you enable interrupts, etc. This would require some work on code segments though. - Ark
If you used a PICSTART or similar 'development only' programmer, your code 
was never verified at the extremes of power supply voltage for that device. 
Most likely you've got a couple of leaky FLASH cells, or have had a 
significant zap.

Zaps to i/Os can cause problems such as this.

Using parts outside their operating range can also exacerbate it. ie 4MHz 
part at 20MHz, 5V part at 2V etc.

-Andrew




<cbarn24050@aol.com> wrote in message 
news:1109529998.653915.35630@o13g2000cwo.googlegroups.com...
>I have about 20 units in the field using the PIC16f870. Some have been > in use for nearly 2 years without any problems but recently 2 units > have come back as faulty. They have the same symptons, the program > crashes during its interrupt routine, it doesn't return, it doeas > execute the first few instructions though I can tell how far it gets > before it crashes. After 15mS the watchdog resets and the cycle > repeats. There appears to be no hardware faults anywhere. Ive read the > data eeprom values and they are as expected, I can't read the code as > its protected. Low voltage programming is disabled and code protection > bits are set. The program does not have any routines for writing to > code memory. If I reprogram the chip with the same software it now > works faultlessly. Anyone got any ideas? >
You could have a point there, im sure the programmer doesn't verify at
anything other than 5 volts but do any? I'm using at 5v, 8Mhz for a
20Mhz part, I/Os don't leave the board. Do you think running the micro
at it's max and min supply voltages is a test worth doing, I mean will
it actually prove anything?

They are fitted to small units, they go all over the place, not enough
have failed to establish any common reason. I'm not quite sure how the
rest of your post would help, perhaps you could elaborate.

Hi anonymous,

> You could have a point there, im sure the programmer doesn't verify at > anything other than 5 volts but do any? I'm using at 5v, 8Mhz for a > 20Mhz part, I/Os don't leave the board. Do you think running the micro > at it's max and min supply voltages is a test worth doing, I mean will > it actually prove anything?
As I work with PICs, I know that Microchip advice to use a production-grade programmer for other than develompent. It's read opearation by the min and max Vdd is the prescribed way to verify a programmed PIC. Hope, this helps. Michael --
Hi anonymous,

> I have about 20 units in the field using the PIC16f870. Some have been > in use for nearly 2 years without any problems but recently 2 units > have come back as faulty. They have the same symptons, the program > crashes during its interrupt routine, it doesn't return, it doeas > execute the first few instructions though I can tell how far it gets > before it crashes. After 15mS the watchdog resets and the cycle > repeats. There appears to be no hardware faults anywhere. Ive read the > data eeprom values and they are as expected, I can't read the code as > its protected. Low voltage programming is disabled and code protection > bits are set. The program does not have any routines for writing to > code memory. If I reprogram the chip with the same software it now > works faultlessly. Anyone got any ideas?
If reprogramming solves the problem, it looks like some bad, but not broken cells in the flash rom. As described, use a production-grade programmer, if you can. Michael --
On 28 Feb 2005 00:40:03 -0800, the renowned cbarn24050@aol.com wrote:

>You could have a point there, im sure the programmer doesn't verify at >anything other than 5 volts but do any? I'm using at 5v, 8Mhz for a >20Mhz part, I/Os don't leave the board. Do you think running the micro >at it's max and min supply voltages is a test worth doing, I mean will >it actually prove anything?
Sure, if the chip starts working at one of the extremes you'll have a very good indication of the source of the fault. Personally, I think this is a long shot, but it will eliminate the excuse (which Microchip will give you as well). You've got a huge failure rate there and obviously need to address it. You can look at the date codes on the chips and see if there might be a chip issue, but that's an even longer shot. How about some more info about this application-- What is the electrical environment like? Where does the power come from? What are the I/O pins doing? Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
<cbarn24050@aol.com> schreef in bericht
news:1109580003.757603.277650@f14g2000cwb.googlegroups.com...
> You could have a point there, im sure the programmer doesn't verify at > anything other than 5 volts but do any? I'm using at 5v, 8Mhz for a > 20Mhz part, I/Os don't leave the board. Do you think running the micro > at it's max and min supply voltages is a test worth doing, I mean will > it actually prove anything?
Mine verifies at 4.5V and 5.5V. It proves that you are not sitting on the edge of a cliff. 2 out of 20, such small numbers don't prove too much either. 200 out of 2000 would be more alarming ;) Maybe you half-zapped the chips during the first handling. Could be the contacts of the programmer socket were dirty, two years ago. I had that once with a PLCC programming adapter, kept me puzzled for a good afternoon. 50% of my eproms didn't verify! You would be amazed if you put such an adapter under a 20x microscope, looking at the contacts. Pretty amazing stuff you can find there ;) -- Thanks, Frank. (remove 'q' and 'invalid' when replying by email)