PIC18F67K22 Erased code What happened

[soonc]

Suddenly the code did not run anymore.
As this was experimental code I was able to read a good unit and the unit that stopped working.
The chip is a PIC18F67K22 .
The code that got clobbered is at the very start of code after the boot loader.
I looked at the boot loader code because it's the only way I could see that my code could erase a block.
However there are lots of conditions that have to be met before the boot loader code could possibly do this, and I can't see that could happen when no request to boot load was ever setup.

First: The unit has to be connected to by Bluetooth, and the Bluetooth module's "connected" pin has to be high. If it's NOT connected the boot load cannot proceed.

Second: The PC program has to send a two byte code (making it a 65535:1 chance of happening randomly.) to allow the boot load to proceed.

Third: Each line of the modified Intel HEX carries an extra ChkSum and the line is rejected if the calculated ChkSum does not match the sent ChkSum.

I find it hard to accept that all of the above conditions could be true for the loader code to proceed to do a Block Erase.

So my questions are:

Has anyone heard of code being unintentionally erased ?

What could cause such a problem ?

Yes! it could be my code, but I don't think so.

Thanks.

Good code: Normal Intel HEX
D <! :1008000048EFB0F0FFFFFFFF046ED8CF05F0E0CF58
D <! :1008100006F00001E9CF0CF0EACF07F0E1CF08F0D5
D <! :10082000E2CF09F0D9CF0AF0DACF0BF0F3CF12F014
D <! :10083000F4CF13F0FACF14F0F5CF15F0F6CF16F091
D <! :10084000F7CF17F0F8CF18F0FBCF19F000C00EF07B
D <! :1008500001C00FF002C010F003C011F09DA034EFF2
D <! :1008600004F09EB03FEF17F0A0A23AEF04F0A1B25F
D <! :1008700059EF17F0F0A640EF04F0F0B031EF17F0A9

Unit that Stopped working:
I !> :10080000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8
I !> :10081000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE8
I !> :10082000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD8
I !> :10083000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC8
I !> :10084000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB8
I !> :10085000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA8
I !> :10086000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF98
I !> :10087000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF88

[PCM programmer]

1. Post your #fuses and #use delay() lines, and any #device lines.

2. Post if you're compiling in Debug or Release mode.

3. What is the Vdd voltage connected to your PIC ?

4. Do you have all required connections as shown in this section of the
18F67K22 data sheet, especially ENVREG and Vcap/VDDcore and all
the individual bypass caps on the Vdd pins:

[Ttelmah]

What is connected to your MCLR pin?.

Partial erasing _can_ sometimes occur if this pin goes above Vdd. There is no clamp diode on this pin, and if it is not protected by such a diode, and has some circuitry attached, and some RF, with nothing to pull it down, it can act as a radio receiver, and charge to a voltage above Vdd. Individual blocks then erase depending on the thresholds for different parts of the chip...
The 'minimum connections' shown in the page referred to by PCM_programmer, have it clamped to Vdd, and a capacitor to ground (I'd personally add a reverse biased diode across R1 - this is shown in many sheets for other chips), to ensure that it is never significantly above Vdd.

Best Wishes

[soonc]

PCM Programmer and Ttelmah,
Thanks for your replies.

Vdd is 3.3V

100nF X7R caps at all Vdd pins (within 3-4mm of pin)

One Tantalum 10uF on Vdd very close to one of the uP Vdd pins.

ENVREG pin is Grounded because I'm not using the internal reg.

R1=33K R2=220 Ohm C1=1uF I always use the Extra Diode connected
across R1 Cathode to Vdd as suggested by Ttelmah.

Good solid copper ground plane for 0V and Vdd line is not very long to actual regulator (Linear LT1844-3V3) Reg. is decoupled as per Linear's recommendation. LT1844 get 3.65V from a (two D cell) MAXIM DC-DC capable of delivering 500mA.
The raw power is not noisy.

I need to check and see if there are any glitches at power up.
The DC-DC is always ON and only draws 30-40uA when unit is switched off.
So I feel sure it's ready to handle the switch on surge, but I did not look for glitches or V over shoots. I'll do that now.

Compiler: CCS V4.135 I also have the newest but most units were programed with V4.135.

FUSES: Not the unit that failed was programmed with no protection but protected units failed also. I needed to be able to read the uP and it took over 2 months of daily/use testing for the problem to happen.
Code is compiled for release.

Is it really needed to set WDTxxx to a value when NOWDT is used ?

Thanks again for your suggestions.

[PCM programmer]

There was once a guy who PM'ed me about a very similar issue.
It was either bootloader code or internal eeprom that was being erased.
I think it was the program code.
I had him read the fuses from the PIC and in the affected units the
brownout voltage was set to 2.0v, and in the good units it was 4.5v.
Somehow some of his units were programmed with the wrong fuses
and shipped out into the field. He never came back so I think this
cured his problem.
I notice you don't have brownout enabled, probably because this is
a low power battery-operated device. According the the 18F67K22
data sheet, high-power brownout mode only requires 4.5ua at 3.3v.
In high-power brownout mode the trip levels for BORV30 are 2.82v
min and 3.18v max. So you could try enabling that one, or at least
try BORV27.

[soonc]

[PCM programmer]

I can do that, but can you post your #use delay() statement and your
external crystal or oscillator frequency ?

[soonc]

[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