mystery software (?) death

[[email protected]]

hello, I was wondering if anyone had ever encountered something like
my latest joy.

summary:
unit stops working, yet when you read in the program and e2prom space,
the data looks fine and when reprogrammed, the chips (and circuit)
work fine

details:
we have a circuit using a PIC12F629 with softwareA. been using it for
years. no problem

now, same circuit, new softwareB.

does the same basic thing as A. we developed it, tested it debugged
it. sent it out.

now (after about 80 of the units were assembled and 40 shipped out).
we start seeing these failures.

example:
a unit assembled and burned in here at the plant for less than 1.5
hours.. found dead

2 units, sent in the field, worked.. a day, a week.. then died

so we recalled everything and set 10 units, non-encapsulated, to run
in the lab

after about 2.5 days, one died. being unencapsulated, we were able to
take the chip and read it using our programmer (Promate II).

my original suspicion had been that the E2prom was getting scrambled.
something I had encountered in another project and which could have
resulted in a situation where the program functions, the chip pins are
fine.. but the orders which were in E2prom are now gibberish and so
the unit appears to be dead.

but, when I read this chip. everything was perfect. software
identical to what was programmed in. OSCAL look healthy. E2prom as
was programmed in

tried a different in the circuit.. circuit worked fine. tried the
'bad' chip in the circuit again.. dead. reprogrammed the 'bad' chip
(to see if maybe pins were missbehaving)... works fine; still working
fine after.. roughly 2 days.

no others of my labrats have died (so they have been on for ~~4.5
days)

anyone with ideas... pretty please!

 

[petrus bitbyter]

hello, I was wondering if anyone had ever encountered something like
my latest joy.

summary:
unit stops working, yet when you read in the program and e2prom space,
the data looks fine and when reprogrammed, the chips (and circuit)
work fine

details:
we have a circuit using a PIC12F629 with softwareA. been using it for
years. no problem

now, same circuit, new softwareB.

does the same basic thing as A. we developed it, tested it debugged
it. sent it out.

now (after about 80 of the units were assembled and 40 shipped out).
we start seeing these failures.

example:
a unit assembled and burned in here at the plant for less than 1.5
hours.. found dead

2 units, sent in the field, worked.. a day, a week.. then died

so we recalled everything and set 10 units, non-encapsulated, to run
in the lab

after about 2.5 days, one died. being unencapsulated, we were able to
take the chip and read it using our programmer (Promate II).

my original suspicion had been that the E2prom was getting scrambled.
something I had encountered in another project and which could have
resulted in a situation where the program functions, the chip pins are
fine.. but the orders which were in E2prom are now gibberish and so
the unit appears to be dead.

but, when I read this chip. everything was perfect. software
identical to what was programmed in. OSCAL look healthy. E2prom as
was programmed in

tried a different in the circuit.. circuit worked fine. tried the
'bad' chip in the circuit again.. dead. reprogrammed the 'bad' chip
(to see if maybe pins were missbehaving)... works fine; still working
fine after.. roughly 2 days.

no others of my labrats have died (so they have been on for ~~4.5
days)

anyone with ideas... pretty please!

Strange indeed. Two possibilities comes to my mind:
- The programmer. Does the programmer overstretched the units somehow? Does
it use the correct programming sequence? Especially when a 629 has been
programmed with the MCLR as an input pin, the correct sequence of VCC and
VPP is important to make sure the chip comes in the right programming state.
- Handling. ESD sometimes has strange effects on flash programmed devices.

petrus bitbyter

 

[Jamie]

hello, I was wondering if anyone had ever encountered something like
my latest joy.

summary:
unit stops working, yet when you read in the program and e2prom space,
the data looks fine and when reprogrammed, the chips (and circuit)
work fine

details:
we have a circuit using a PIC12F629 with softwareA. been using it for
years. no problem

now, same circuit, new softwareB.

does the same basic thing as A. we developed it, tested it debugged
it. sent it out.

now (after about 80 of the units were assembled and 40 shipped out).
we start seeing these failures.

example:
a unit assembled and burned in here at the plant for less than 1.5
hours.. found dead

2 units, sent in the field, worked.. a day, a week.. then died

so we recalled everything and set 10 units, non-encapsulated, to run
in the lab

after about 2.5 days, one died. being unencapsulated, we were able to
take the chip and read it using our programmer (Promate II).

my original suspicion had been that the E2prom was getting scrambled.
something I had encountered in another project and which could have
resulted in a situation where the program functions, the chip pins are
fine.. but the orders which were in E2prom are now gibberish and so
the unit appears to be dead.

but, when I read this chip. everything was perfect. software
identical to what was programmed in. OSCAL look healthy. E2prom as
was programmed in

tried a different in the circuit.. circuit worked fine. tried the
'bad' chip in the circuit again.. dead. reprogrammed the 'bad' chip
(to see if maybe pins were missbehaving)... works fine; still working
fine after.. roughly 2 days.

no others of my labrats have died (so they have been on for ~~4.5
days)

anyone with ideas... pretty please!

Yes, have any inductive or high energy near it?

 

[[email protected]]

thank you to everyone who threw ideas out there!

looks like the reason the unit seemed to 'die' was that that version
of code wasn't prepared to deal with garbage in the one byte I write
to. my very bad. I can make so that units keep working when garbage
drops in.. but there will be interference with the product function..
such that if it happens more than once, our clients are going to have
fits

so the question is redefined as: how can I avoid garbage getting in?

assuming (and this is an assumption) that the garbage entered by way
of a weird power problem (brown out..?) at a bad moment (say in the
midst of a write)
1) I have _BODEN_ON & _PWRTE_ON.. isn't that supposed to make brown
out a non-fatal thing?
2) is it possible for the weird power problem to cause garbage to
appear in a location other than that which I was trying to write to?
this would be extremely scary..
3) if in user memory I save the data and address I was trying to
write. could I check on every 'processor reset' if there was a write
err... and would data in user space be safe after such?
4) anyone have any tricks to safeguard operation? in this case there
is only 1 byte I ever write to, but the next project I have to do
would have up to 4 bytes that would get written to regularly

 

[[email protected]]

thank you to everyone who threw ideas out there!

looks like the reason the unit seemed to 'die' was that that version
of code wasn't prepared to deal with garbage in the one byte I write
to. my very bad. I can make so that units keep working when garbage
drops in.. but there will be interference with the product function..
such that if it happens more than once, our clients are going to have
fits

so the question is redefined as: how can I avoid garbage getting in?

assuming (and this is an assumption) that the garbage entered by way
of a weird power problem (brown out..?) at a bad moment (say in the
midst of a write)
1) I have _BODEN_ON & _PWRTE_ON.. isn't that supposed to make brown
out a non-fatal thing?
2) is it possible for the weird power problem to cause garbage to
appear in a location other than that which I was trying to write to?
this would be extremely scary..
3) if in user memory I save the data and address I was trying to
write. could I check on every 'processor reset' if there was a write
err... and would data in user space be safe after such?
4) anyone have any tricks to safeguard operation? in this case there
is only 1 byte I ever write to, but the next project I have to do
would have up to 4 bytes that would get written to regularly