two PICs in the same socket fail to start

[zilog]

In order to eliminate the suspicion that our PIC is broken, we have disabled the reset-pin to the original pic, and piggybacked another identical on top of the old one. We can get ICD-communication to both pics by toggling the reset-pins, but we cant get the crystal oscillator (HSPLL-mode) to work using this configuration.

It seems like one or both the pics drive the crystal pins low, but fail to start oscillating. Could this be due to the piggy-backing, and then how do I best circumvent the problem? Desoldering the old pic is not an option as the PCB can take no more punishment..

The PIC in question is a 18F66J15, using 2.5V supply and 10MHz external crystal.

[Ttelmah]

Unless the two oscillator inputs, just happen to have _exactly_ the same switching point, one will try to switch before the other, and it's output will try to drive low, at the same time as the other is trying to go high. Result, deadlock...
Disconnect the OSC2 pin on the piggbacked chip. This way it'll run using the oscillator on the other chip. However behaviour is still going to have a lot of risks of conflict (remember that the timings of startup, may well differ by a few clock cycles...).
It is not really a thing that is likely to work terribly well.

Best Wishes

[Mogge]

Hi

I am the hardware guy in this project where zilog is programmer.

Yes your idea, Ttelmah, to clock one PIC from another would work if it was not for the fact that the oscillator in xtal mode do not start at poer up is reset is held active. (Once started however, it contionues to run if reset goes active)

When we just parallelled the outputs it was as i thought the OSC driver also got tristated by reset, that was wrong. ( But It does get tristated if the osc do not start and the pic internal backup oscillator takes over)

I now have separate crystal cirquits for each processor, and they work as intended.

So now all pins are parallelled except OSC and reset.
Reset is switched by a tiny DPDT switch wiht short wires to connect one old or nwe processor /MCLR to GND, and the other to the normal reset line.

When selected, the old processor works as before, same problems.
And by flipping the switch we select the other.

I can not find any reason this sheme should have problems, as a processor in reset will release all pins to hi-Z, except osc. Or is it not so?

We also looked at the Microchip PICDEM HPC Explorer which we used in beginning of theis development, where the piggy back processor module parallells the base module processor. Ther they have another strategy, they pull the VDD for the chip they do not use, which we find weird, as that put more load on the signals driving the PIC. But switchng off VDD they managed to parallelled also the osc pins. But i find our design more reliable.

Right now we are working to see if there is any different behaviour between the two chips.

[Ttelmah]

I can understand the problem, but am actually supried that it doesn't cause problems int the mode without power. The internal protection fuses are quite capable of powering one PIC from another...
The reason there may be difficulty, is that several bits (noticeably ICD), actually wake up, as soon as the chip is powered, and only go off, once the configuration fuses are 'read', which happens as soon as the clock is present. This is also why the oscillator then keeps running. Personally, I'd probably just program the bottom chip to run, with a small program that puts all pins into input mode, disables the peripherals, and then does nothing.

Best Wishes

[Mogge]

Well....
In practice this method of stacking the PICs works for us: the "old" PIC executes the same program with the same randomly occouring errors as before, and flipping the switch we see the new chip does the same.

-Unfortunately... (it at least proves it is not just a problem in a single chip individual)