PIC18F67K22 Erased code What happened

[PCM programmer]

The Config bits from your hex file match what you put into you have in
your #fuses line.

These are the fuses reported at the end of the .LST file for a program
with your #fuses statements (with _NOT_PROTECTED_ defined).
I put the INTRC_HP in brackets because that's a bug in the compiler's
Config bits report. The bug is still there in vs. 5.020.
In some cases the settings may seem strange, for example with brownout
it has Zero Power Brownout mode selected, but that's the default if you
don't specify it, and you're not enabling brownout anyway so it doesn't
matter.

[soonc]

Thanks for decoding those fuses.

Is there a utility that can decode the HEX or did you do it all manually ?

Power Glitches:

There are no power glitches in excess of 3.3V BUT there is one big power glitch (dip) 1.3mS after power up. It dips about 1V.

Power up ramps up in 500uS. Clearly that's not good.

Power down is clean.

Thanks for all the help.
I'll post my finding if/when I get a result I can trust and repeat.

[PCM programmer]

I did the fuses manually.

The slow ramp up and the glitch in the power supply output are probably
causing the problem.

[soonc]

I'll investigate the power glitch some more.

I appreciate you taking the time to decode the Fuses.
Perhaps it's a feature CCS could add to the IDE.

May be it's already "in there" but I have not seen it.

[PCM programmer]

You can import the hex file into MPLAB. First go to the Configure menu
and select the correct PIC. Then go to File/Import and import the Hex
file. Then got to Configure/Configuration bits and you'll see the Config
bit fields and their settings.

[soonc]

Thanks that's a great tip.

BTW the power up ramp really was not an issue: What was NOT GOOD was the glitch that happened right after power up.
I've fixed that, and have rigged up a system to cycle the power ON and OFF every 120 Seconds. I'll leave it running for a few days.

Thanks again for the help.

[Ttelmah]

Have to agree. The ramp time is well inside the figures allowed from the data sheet (yes this is specified). However the glitch is bad. Realistically, this _is_ a brownout, so I have to ask why the brownout fuse is 'off'. Even if you fix the core problem, worth possibly having the 'belt and braces' of enabling this as well.

Best Wishes

[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