Flash code corruption on pic6f870

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

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,

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,

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

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

schreef in bericht news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

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)