TMR2 Jitter

[c_bellsham]

Hi,
We're using an 18F452 in PLL mode driven by a 10MHz clock.
We've set TMR2 running using the Period Register to give us a 100us system tick (using interrups).
When we scope up a pin that is toggled at the interrupt we see a nice 100us interval between ticks.
But occaisonaly it appears to come a little late (2us) which we can account for with other interrupts running at that time.
Waht we can account for is when it appears to come early (or possibly very late). We've minimised the calls from the interrupt routines so it doesn't go off for a long time doing something else.
Does anyone know if the processor PLL can some times jitter off frequency?

[Ttelmah]

First comment. I'd expect more than 2uSec jitter at the worst case, from other interrupts. When an interrupt occurs, there are something like 30 instruction times used to save the registers. Then about 4 instruction times for the 'tests' for each interrupt that has a higher priority than the one being serviced. Then the interrupt subroutine itself, and then another thirty instruction times restoring the registers before the exit. Now the 'worst case', would be where the timer interrupt occurs in the very next instruction, after it has been tested for. In this situation,assuming that the other handler involves perhaps 20 instruction (a small handler), you could well have something in the order of 50 to 60 instruction times involved, before the chip can service the timer interrupt. I'd expect to see at least 5 to 6uSec of jitter from this cause, and if the other handler has anything like array accesses in it, even more...
Now you don't mention what order the interrupt handlers are declared in (or what you have in a priority statement), but this could make things even worse.
Ongoing, if there is another interrupt event, that has a higher priority, and it happens to get close to being 'synchronous' to the timer event (serial at 115Kbps for example), then you could ge the situation where successive timer interrupts are delayed by an ever increasing amount, and then suddenly jump 'back' to being serviced in front of the other event. This would give the sort of 'jitter' that you are seeing.
Now the PLL, can lock on to an overtone, if it is being overdriven. On the relatively early 18F chips (of which the 452, is one), the oscillator is more sensitive in PLL mode, and getting it reliable, may need a series resistor. However once locked to such an overtone, it is unlikely to change again, so running 'off frequency' was a common complaint when these chips were launched (reduced on latter steppings), but 'jitter' is not likely. The only person wo can really test this is you. Program a chip, just using the hardware CTC, to develop a constant square wave. If it's frequency is as expected, and does not change, you have your answer here.
Is it possible that you have some supply noise, causing a reset, or possibly are not correctly retriggering the watchdog, and so are getting the occassional 'break' in the clock stream?. This would give the 'very late' response.

Best Wishes