PIC24FJ1024GB606 Intermittent startup issue

[Ben1172]

Having an intermittent power up issue in which occasionally (~1 a day) I get no output from PIC24FJ1024GB606 on power up. Once it goes down, cycling power or asserting master reset has no effect in getting the PIC to operate again. The only way to make the device run again is to connect it to my ICD-U64. After I connect, all that is needed is to command run and it works again. I can remove the programmer and cycle thru hundreds more power up sequences before the fault occurs again. When I connect to the U64, if I choose verify it passes.

When it doesn't work, I get no activity on any of the IO. Normal troubleshooting doesn't work because any attempt to connect to a debugger fixes the problem.

I have verified the rise rate and monotonicity of the power supply, ESR of VCAP, and reset line. I have implemented a manual switch-over for the PLL in software in case it was similar to the issues experienced with some 24EP series PICs (made no difference). No correlation noticed with temperature (happens as often from cold start as hot).

The fact that when the PIC goes bad it is done until connecting with a programmer is a big clue, but I don't know enough about the ICD-U64 to grasp what is going on.

IDE is 5.073
ICD is 5.042, firmware is 3.21

Fuses:

[newguy]

The PLL reminds me of a problem I had with a dsPIC. Turns out the dsPIC on the CCS DSP evaluation kit is equipped with a 12MHz crystal, and, way down deep in the bowels of the data sheet for that processor, it states that the PLL isn't specified to run from an external crystal > 8 MHz (I believe) on startup.

Can you, just for testing, change the clock to run from 8 MHz internal (if that's possible) WITHOUT the PLL? Just some rate that's low enough to run directly from the internal oscillator only. See if it hangs without the PLL enabled/used. The clock setup (or switchover for that matter) has "wait until stable" or somesuch test. If the clock isn't reliably configuring the PLL, it's conceivable that the processor would hang but I'm struggling with your observed behaviour re: cycling power makes no difference. I suppose that it could be a silicon issue (is the PLL mentioned at all in the errata?) and the connection of a programmer (and the high voltage on Vpp) "snaps it out" of its zombie behaviour.

[Ttelmah]

How do you have the ICD lines connected/programmed?.

Program these as output low in your code, or have a large value pull down resistor on them.
If these float, the chip won't run. The ICD controls these, and will pull them down when not programming.

[Ben1172]

Okay, I made the change to output low the programming pins in code, though I'll be pretty surprised if that works (it could take a few days to confirm). After all, if the PIC is hung up then the code won't be executed.

And while I am not doing it, aren't those pins allowed to be used as general IO?

But you never know....and I am losing hair over this....

As to reprogramming just using the internal 8MHz, that will be a lot of work, and I might not be able to get it going. But I'll look into it. Also want to look into if VPP for these PICs is at a higher voltage, I might be able to use that in a pinch to Kluge my way out of this.

Thanks for the replies.

Ben

[Ttelmah]

Using them as general I/O, can be a little complex.

First thing is that obviously you can't debug code that uses them....
Then you can't have pullups on these pins (will prevent the ICD from working).
In fact in general you can't have anything that prevents them being clocked high, at reasonable speed (so no capacitors) or will pull them above 0.6v when MCLR rises, with them being pulled down by about 4K7R. So anything pulling up with more than about 1/4mA.
Also the actual connections to the ICD header, need to be pretty direct (short, no resistance above perhaps 200R, and no diodes in line).

Now, this is all 'worse' on the later chips like the PIC24. These effectively always operate in LVP mode. Unlike older chips that needed a relatively high 'Vpp' voltage on the MCLR pin before they would trigger programming, the programming mode is entered on these larger PIC's, by a state machine triggered by the pattern of signals on MCLR PGC, and PGD. Now I've found that some of the chips seem to be prone to 'thinking' that you are starting a program sequence, if PGC in particular floats at all as the MCLR rises. When this happens, they don't actually program (since they don't see the rest of the sequence needed), but they just stop working....
Now like most things on the PIC, though you would think the actual state machine implementation would be the same between the various chips in the families, and (obviously) the main implementation has to match for the programmers to work, I've seen particular chip 'models', that seem much more prone to problems than others.

Because of this I've taken to always 'not using' the PGC pin in particular (and if I want to use PGD, having a jumper to disconnect this from any I/O), and having a 10K pull down resistor on the PGC pin.
Before doing this I was having just odd occasions when the chip would not boot. Since, they seem to be 100%.

The debugger pulls these pins low with 4K7R. That this makes your chip work, suggests the problem is with them floating.

[Ben1172]

Nice response, very informative.

Then to give this solution a fair shot, I will add a 10k pulldown on the program clock

[Ben1172]

FYI,

Problem still occurs with PGEC and PGED 10K pull downs and output_low in code.

Problem still occurs when PLL is not used, operating from internal 8MHZ osc only.

No related errata.

Although it is a somewhat ridiculous hack, I will try adding a small PIC to the programming header that will emulate the U64 by entering and exiting programming mode on each power-up of the 24FJ1024. Sad.

[Ttelmah]

I see you have posted on another thread, that it is an oscillator issue, with the internal oscillator and the PLL.

I'm using another chip in this family (less ROM), and it has been fine, but I'm using EC. Had cause to need an accurate crystal, for this and another device, so an 8MHz oscillator was the easiest way to go.

Definitely a 'caveat' for anyone using the internal oscillator....

[Ben1172]

A small pic on the programming header that enters then exits programming mode on every power up does sidestep this problem. Its a ridiculous solution that is only justified because of a time pinch. If anyone ever experiences this and figures out the real issue and solution, I'd appreciate hearing about it

Ben