Do you have a question? Post it now! No Registration Necessary
Threaded View
Subject
- cbarn24050
February 27, 2005, 6:46 pm
Reply
Save
Print
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?
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?
Re: 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
Re: Flash code corruption on pic6f870
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
Re: Flash code corruption on pic6f870
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?
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?
Re: Flash code corruption on pic6f870
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"
snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com
"it's the network..." "The Journey is the reward"
snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Flash code corruption on pic6f870
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)
Thanks, Frank.
(remove 'q' and 'invalid' when replying by email)
Site Timeline
- » Reverse current into a lithium battery
- — Next thread in » Embedded Programming
-
- » Fuzzy Systems with Microcontroller (embedded)
- — Previous thread in » Embedded Programming
-
- » Use of soft float?
- — Newest thread in » Embedded Programming
-
- » arm-gcc: avoid calling other system functions
- — Last Updated thread in » Embedded Programming
-
- » Telko SY052X
- — The site's Newest Thread. Posted in » Electronics Repair
-
XML Sitemap