# PIC18F2620 Internal Clock Jitter

I have a circuit board that uses the PIC18F2620 SOIC device. I am set up to use the internal clock at 8Mhz and and PLL to get FOSC to 32MHz. FOSC/4 is output on pin RA6/CLKOUT to a logic analyzer. The trace below shows jitter on the clock unlike what I've seen with other PIC18Fs. See below. I used auto-store to capture/overlay many cycle on this trace display. The jitter can be seen on the display.

I am using the following code to set the oscillator:

static void OSC_Init(void)
{
OSCCONbits.IRCF    = 7;       // Internal Oscillator to 8 MHz.
OSCCONbits.SCS0    = 0;       // Set system clock to use...
OSCCONbits.SCS1    = 0;       // ... primary oscillator.
while (OSCCONbits.IOFS == 0); // Wait until INTOSC is stable.
OSCTUNEbits.PLLEN  = 1;       // then PLL Enabled (8Mhz x 4 = 32 MHz).
}


My configuration bit settings are as follows:

#pragma config OSC     = INTIO7  // Internal osc, CLKOUT on RA6, port function on RA7.
//#pragma config OSC   = INTIO67 // Internal osc, port function on RA6 and RA7.
#pragma config WDT     = OFF     // WDT disabled (control is placed on the SWDTEN bit)
#pragma config FCMEN   = OFF     // Fail-Safe Clock Monitor = OFF.
#pragma config IESO    = OFF     // Oscillator Switchover mode disabled
#pragma config PWRT    = ON      // Power-up Timer Enable bit: enabled
#pragma config BOREN   = OFF     // Brown-out Reset disabled in hardware and software
#pragma config XINST   = OFF     // Extended Instruction set disabled
#pragma config PBADEN  = OFF     // PORTB<4:0> pins are configured as digital I/O on Reset
#pragma config STVREN  = ON      // Stack full/underflow will cause Reset
#pragma config LPT1OSC = ON      // Timer1 configured for low-power operation
#pragma config MCLRE   = ON      // MCLR pin enabled; RE3 input pin disabled
#pragma config LVP     = OFF     // Single-Supply ICSP enabled
#pragma config CCP2MX  = PORTC   // ECCP2/P2A is multiplexed with RC1


I've read all of the errata datasheets from Microchip, but the internal clock is not listed as having errors.

Is the internal clock of the PIC18F2620 really that unstable, or should I be looking for something else as the cause?

Would the configuration bits set to INTIO7 for monitoring the CLKOUT line affect this?

Should I be thinking about going to a crystal to improve stability?

Thank you for any help and insight to this problem.

• Internal clock is an RC type: not nearly as stable as a crystal source. Its clock jitter gets multiplied by 4 in the PLL. – glen_geek Dec 23 '17 at 0:33
• @glen_geek Hmm. But that is a good thing. ;) It means the radiated emissions are spread out and that means the device might pass EMC requirements in Europe!! And cheaper than buying a spread spectrum crystal oscillator, too! – jonk Dec 23 '17 at 0:36
• @jonk Ouch! This spread-spectrum sneaky trick is simply spreading the garbage out in the hope no one is inconvenienced enough to complain. Can you tell that I care that the noise floor remains natural? Some chips allow an option to spread it even more! – glen_geek Dec 23 '17 at 1:12
• related: AVR internal oscillator jitter "...most interesting thing is that newer versions of tunable oscillators were generating much more jitter than older ones". – Bruce Abbott Dec 23 '17 at 5:48
• Interesting report @BruceAbbott My conclusion is unrelated. That one shows 0.5% pp jitter which is amplified by delay to 50% on image with 100ns jitter in 10us delay or about 100x magnification. Here there is no magnification and jitter on all edges is 25%pp. I feel the jitter is due to speed changes in chip when they introduced a 4x frequency multiplier than introduced the 0.5% jitter. – Tony Stewart Sunnyskyguy EE75 Dec 25 '17 at 17:30

SOLVED. The problem was the power decoupling of the PIC18F2620 device. I changed the 0.1uF to a larger 1.0uf and then placed an additional smaller 0.01uf in parallel with the first. The 1.0uF intended as a "power resevoir" and the 0.01uF as a noise filter. This configuration cleared up the jitter problem nicely. Thanks to all who posted hints and answers.

Lets compute a Time-Jitter floor for a crystal oscillator. Assume 10MHz with +-1volt sinusoid. We know the exact slewrate SR:

SR = 1vpeak * 2 * pi * freq

SR = 1v * 62.8 million rad/sec = 62.8 million volts per second.

TimeJitter = Vnoise / SlewRate

Assume 0.628 volt spike is coupled thru the ESD diodes, exactly when the internal SCHMIDT circuit triggers to convert the sinusoid into squarewave. What happens?

TimeJitter - 0.628 volts / 62.8 million volts per second

TimeJitter = 10 nanoseconds, even tho you used a magical crystal oscillator.

Can you deal with that?

Note that ANY manufacturer's MCU is vulnerable in this manner.

How to achieve low-jitter? Use a stand-alone box containing ONLY an oscillator. If you must perform the squaring function within that box, use separate VDD/GND pins for the squaring circuit.

• AnalogSys, Thanks for the detailed explanation on how to calculate jitter. – Doug12745 Dec 23 '17 at 21:41
• I guess I should be asking how much jitter can I tolerate. From my scope trace above I would estimate that my jitter is about 25% which I feel is too much. Also, the jitter doesn't appear to be symmetrical. It seems to appear more on the left side of each cycle than on the right. I think I will try an external crystal and compare the differences. Unfortunately, my design is aimed at low cost, high volume production. Adding a \$1 crystal circuit will increase the cost (when multiplied by 1M or so units). – Doug12745 Dec 23 '17 at 21:51

Symptoms:
Excessive FM noise 25% deviation using x4 then /4 frequency conversion 8MHz ref in 32MHz x4 multiplier in PLL then /4 fout shown in scope at 8MHz with frequency jitter on all edges except trigger edge.

Impressions:

This Clock controlled by PLL VCO control noise is is showing excessive FM frequency deviation (25%) , which is why only trigger edge is stable. And all other edges jitter by 25%. Coincidentally or not this is a divide by 4 output.

Review design for causes of hardware or software induced FM.

• CM noise immunity? Does earth grounded make a difference?
• How does it change when choosing 4MHz x4 and 16MHz x4? See if random, wide band, or line rate
• If possible , change FOUT software settings to change and look for stability changes. It is from false counter triggering at 32MHz? or from choice of x4 freq multiplier or choice of 8MHz vs 16 or 4.

Does problem disappear at any time? Can you alter it by doing anything with fingers near chip and gnd? This modulates EMI crosstalk and CM noise.

• Use spectrum analyzer to demodulate and identify modulation rate. This may suggest stronger clues to underlying analog source in jitter. ( impedance mismatch ringing, line f CM noise ingress, or logic crosstalk? )
• Tony, the first sentence seems to be experiencing keyboard jitter. It's not clear what you are saying. – Transistor Dec 24 '17 at 8:14
• Yes... fat fingers on a tiny mobile – Tony Stewart Sunnyskyguy EE75 Dec 24 '17 at 12:57
• The PCB is 4-layer with power and ground as internal layers. Vcc and GND us a 0.1uF bypass cap very close to those pins. Power and GND are applied to the micro through vias from the internal planes. Will add additional bypass and see if that makes a difference. Also, possibly the vias are too small? – Doug12745 Dec 24 '17 at 22:17
• If you don't have a good scope or SA , what other tools can you make use to change the clock rate to decode the jitter rate and find root cause. I might use a dual CMOS SPDT as a S&H mixer driven by a stable XO -<>- to down convert. Active guarding is better, but microvias are OK if critical VCO inputs shielded or active guarded ( ie. surrounded by absorbing low impedance path) – Tony Stewart Sunnyskyguy EE75 Dec 25 '17 at 2:55