PIC18F67K22 Erased code What happened

[soonc]

Ttelmah,
Yes I understand.
Basically the uP keeps it own power ON by raising a "keep alive" line as soon as the simple mechanical Push Button switch is pressed. That works fine but when switching OFF the uP lowers the "keep alive" line and switches off the LDO reg.
If the BROWNOUT is enabled as the system dies it issues a reset and the uP boots up again.
By not allowing the BROWNOUT the shutdown is clean.

The "big glitch" was due to lack of thought on my part I had used a far too large a Tantalum cap at the LDO output and it produced the first bad glitch that I think was the cause for the program wipe out. That glitch is GONE however it exposed a very fast second glitch at about 43mS from when Vdd is switched ON.
The PIC data sheets suggests there is a 65mS power up timer so I don't think this second glitch is under my control except by supplying a lower Z output LDO reg. The LDO is a Linear part LTC1844-3V3 it gets it's RAW DC from a Maxim DC-DC that is always ON. The MAXIM DC-DC can deliver 500mA. The DC-DC runs off of 2 "D" cells.

If I could figure out how to post scope images I'd upload to show you what I mean.

UPDATE on Testing:
I rigged up an automated ON/OFF cycle tester last night and it cycles the DUT power ON / OFF every 90 seconds with enough time to allow the system to drain down to near zero in the DUT each time.

So far it has Switched ON/OFF 183 times with no failures.

[Ttelmah]

Fun...

I'd suggest that by tuning the cap/resistor on the MCLR pin, you should be able to ensure that the chip remains in reset for more than 50mSec after power comes on. Then the high speed glitch shouldn't matter (this may already be what is happening).

Best Wishes

[soonc]

With or without changes to "tune" the RC reset at the !MCLR pin so as to avoid complications with a glitch during power ON I tested using an automated On/Off controller.

Over 2600 on/off cycles each cycle allows the unit to power up for 30 seconds and Off for 30 seconds which is enough time for the Vdd to drain to near 0V.

No failures.

Over 900 test in original condition. No Failures.

Conclusion: Tests are inconclusive.

Final Action:
Removed Cap and Diode on MCLR and installed a MCP10-263 reset generator.
If indeed the failure was due to power up or down, the MCP does a super job of providing a 125mS delay at Power ON ensuring the uP is halted.
At power down when the Vdd falls to 2.63V the MCLR pin is clamped down at GND ensuring the uP is again Halted,

Lesson Learned: Use a Reset generator. Current consumption is < 5uA and cost is about the same because the Cap and Diode are not needed.

Thanks for all the help.

[newguy]

All you've really proven is that when the device is operated in the manner it was designed, it works well. What happens if you alter the automated power on/off test to simulate an impatient user? A user that only powers it up for a second, off for 5, then on again? ...Stuff like that...

I have a feeling you'll find the bug under that type of operating condition(s).

[gpsmikey]

The quote that comes to mind in these cases (working with user interfaces) is "it is hard to make things foolproof -- fools are so ingenious" The users out there come up with more strange ways of doing things that the designer never even thought of that cause strange failures sometimes.
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[newguy]

Here's a classic example of an operator doing something the designer didn't account for with deadly results: http://en.wikipedia.org/wiki/Therac-25