Some Old Chips are failing

[soonc]

I have a few old units using the PIC18LF6720 chips that are losing the program.
Unfortunately the chips were protected so I can't read them to see what exactly got lost or corrupted.

The code uses a fairly normal bootloader, and most of the time boot loading the code cures the problem, and hardware reprogramming also works but if a chip messed up it will also mess up again.

Replacing the chip cures the problem.

I did a fair amount of investigation when this first happened. I had suspicions about Vdd rise time.

Power On rise time is fast: slope to 3.3(V)/462*10^-6(sec) = 7142 V/sec = 7.142 V/mS which is about 150 times faster than the minimum required slope of 0.05 V/mS and MCLR circuit is really not needed.

The MCLR does have the classic RC as shown in most PIC data sheets.
I even tried a reset generator. Of course it may not have anything to do with Vdd rise time or MCLR.

The PUT fuse is set and I've tried not using any MCLR at all.

Nothing seems to help, if a chip first starts losing the code it continues.

Has anyone else had failures of this kind, and if so was there a reason it ?

[temtronic]

Since you can't read them you really don't know that they've 'lost their program'. Now a 'messed' up PIC can be reprogrammed but 'messes' up again indicates to me a possible 'bad memory' problem, perhaps caused by EMI, creating a bad cell or two within the program space.
If 'new' PICs does 'cure' the problem, look at the batch numbers ( production dates) to see if all the 'bad'' PICs are the same batch.

Jay

[asmallri]

[Ttelmah]

You say it has a 'classic RC'. Is this with just one resistor?.

The 'simple' circuit, depending on the size of the capacitor, and the design of the supply, can get the MCLR pin being held _above_ the supply as it falls when you power off. On some chips this can cause a spurious programming operation to start, corrupting some cells....

There are a number of recommended circuits. The one if you use ICSP, has an extra resistor to limit the current into the MCLR pin, and allow this to be pulled high for programming. This also serves to prevent the MCLR pin being taken high during the reset operation.The 'classic' MCLR without this, is OK, on older chips, that actually use the MCLR voltage to program. On these the current required to trigger programming is high enough that it is not likely to happen, unless you have a very large capacitor. However later chips, only use the MCLR as a _reference_ to the programming generator, and the current needed is tiny. On these a method of ensuring that this does not happen accidentally is needed.
On your chip (for example), the actual current needed to start a programming operation, is only 5uA. 10mA is then drawn to actually perform the write, but it it has started, some corruption may occur even if this is not available. Also though the programming voltage is specified as 9v, it can start any-time the Vpp is more than a couple of volts above Vdd.

I was told my Microchip, that for later chips, it was _necessary_ to ensure that the circuit could not draw the MCLR significantly above Vdd, when the power was switched off, or memory corruption could occur on some chips.....

[newguy]

I've not observed this on PICs, but I have noticed age and batch-related failures in other ICs. We've had old Ramtron FRAMs that developed sticky bits (even though they're not supposed to - ever) and the latest issue I needed to figure out quickly involved a Si9979 3 phase brushless DC motor controller IC. I traced the problem to a certain batch code. What was happening was those batch codes would errantly run wide open/stop responding to control input.

As others have said, take a look at the date code on the PICs. If they're all the same AND you have units in the field with a different date code, I'd suspect a bad batch.

[soonc]

[asmboy]

a word about NOT_MCLR / prog pin.

I NEVER use a hardware controlled reset
for the reaon MR. T stated above.

if you don't need an external clear command input.
don't even declare the pin active.

[newguy]

Depends on the noise your device has to endure. I used to use 47k pullup /MCLR to Vdd and in one of my products electrical noise caused it to spuriously reset. I dropped the pullup to 4.7k and haven't had a problem since. I did try several intermediate values but they all reset as well (the lower the R, the less often). The programmer (a CCS load-n-go) handles it, so 4.7k is now my standard pullup value.

[soonc]

[asmallri]