1. Home
  2. Hobby Electronics Basics
  3. mystery software (?) death

mystery software (?) death

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!

Reply to
rnlbel4me
Loading thread data ...

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

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

Reply to
petrus bitbyter

Yes, have any inductive or high energy near it?

--
"I\'m never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5
Reply to
Jamie

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
Reply to
rnlbel4me

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
Reply to
rnlbel4me

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.