Timing stability of MCU PLLs

[WatchfulEye]

I've reactivated some personal MCU projects after a hiatus of about 15 years - and these days, things are all high speed and running off internal PLLs, when I was used to clocking MCUs of crystal oscillators.

One of my first projects was just a very simple interval timer. I used a microchip ARM M4 (SAMD51) MCU clocked to 120 MHz from the interal PLL which was driven from an external crystal. However, I've found the event capture/timestamp peripheral to record much more timing jitter than I was expecting.

Testing with a 100 Hz signal from a signal generator, revealed a p-p period jitter of over 1000 clock cycles (about 8 microseconds) which I found surprising. So, I tried it with a GPS receiver PPS output, which was only marginally better (about 600 clock cycle jitter on the PPS pulse edge).

I'm curious if there is some sort of user error here, as I was expecting better performance. One thing I'm suspecting is my choice of dev board (adafruit arduino clone - metro m4 express) which is equipped with an external 32.8 kHz crystal, rather than anything faster (and inconveniently the MCU's MHZ range XO pins are not exposed) - if this is the case, is the PLL frequency multiple of 3665 a bit too high to give good stability?

[ataradov]

How exactly do you capture the period?

This is is definitely out of any reasonable bounds. So something is not right.

Reference source should not matter that much. PLL works better with a reference around 2 MHz, but using 32 kHz as a reference is normal.

Note that there is an errata about reference < 400 kHz. You may be running into it. Make sure that OSCCTRL.DPLLCTRLB.LBYPASS = 1

[WatchfulEye]

The period is captured with one of the timer/counter (TC) peripherals. It's operated in input capture mode with timestamping. An ISR is used to retrieve the captured timestamps.    The TC is operated in 32 bit mode with an overflow ISR to keep track of the high word. The TC is clocked off the 120 MHz clock which is also used by the MCU core.

Thanks for info on the erratum. However, I've checked and LBYPASS is 1.

I've done some further testing. I used one of the TCC peripherals to generate a PWM signal, and then routed that signal into the input capture pin of the TC. When the PWM source is clocked off the 120 MHZ core clock via a prescaler, I get +/-1 cycle measured jitter, which is what I was hoping for. When the PWM is clocked off the 32.8 kHz XO then I get hundreds of cycles of jitter, suggesting that it is the 120 MHz clock that is unstable.

I've been through the PLL section of the datasheet, and run a program to brute force through the various filter options. I seem to have improved things a bit, by turning off delta-sigma modulation and increasing the loop filter bandwidth to maximum. With the best settings, jitter on the 100 Hz signal is down to about 600 cycles. The following is a histogram (cycles per 10 ms period) of a short run of 100 Hz signal with the best PLL settings, but even so, the jitter is still significant.



I think the next step will be to try and use an external oscillator, and use one of the GPIOs as an input to one of the MCU's clock generators.

[ataradov]

Also check coarse and fine step settings. Often frameworks use  large values, which speeds up lock time, but may not be great for jitter.

And another, even more critical thing is to check that you are not using buck converter for the VDDCORE. There is even worse errata about that - 2.19.1 "Buck Converter Mode".

Table 54-53. "Fractional Digital Phase Lock Loop Characteristics" says that typical period jitter for f_IN = 32 kHz, f_OUT = 200 MHz is 3.4 % (max is 4.9%).

So it looks like you are below that, if I did not get confused by math.

[Foxxz]

If you are using the Arduino framework for precision timing you should be aware that there are probably some timer interrupts/overflows happening that aren't explicitly shown in your sketch. There are instructions for disabling them that may impact some of the built in functions.

[ataradov]

If you are using the Arduino framework for precision timing you should be aware that there are probably some timer interrupts/overflows

He is using TCC's hardware capture function. It is not affected by any interrupts or software delays (within reason). At least that's the way I read the description of the method.

[PCB.Wiz]

One thing I'm suspecting is my choice of dev board (adafruit arduino clone - metro m4 express) which is equipped with an external 32.8 kHz crystal, rather than anything faster (and inconveniently the MCU's MHZ range XO pins are not exposed) - if this is the case, is the PLL frequency multiple of 3665 a bit too high to give good stability?

Some (most?)  MCUs that lock using the 32Khz oscillator, do not use an analog PLL, but instead use a trim-lock DFLL - ie they check the on chip RC oscillator and snap that to the nearest trim point to correct.
USB MCUs which lock to the 1ms USB frame use this digital locking design too.
The long average is crystal locked, but the jitter is of RC oscillator levels.
If you need lowest jitter, can you find a HF crystal board to try ?

[ataradov]

There are both DFLL for 48 MHz output (used for USB) and a true DPLL, which is tested in this case.

[harerod]

Sidenote: Sometimes a slight jitter is desirable to lower the radiated emissions at MCU clock frequency by spreading it a bit over the spectrum. For example, the STM32F407 has this feature. The same trick may be used by other switching elements, e.g. DCDC-converters. EMC compliance tests account for this by defining narrow band and wider band absolute maximum levels.

[David Hess]

I would configure a timer/capture unit for a square wave output and measure the jitter with an oscilloscope to find out if the jitter is inherent to the microcontroller's internal clock.  One trick might be to trigger the oscilloscope on the 32 kHz source to make this measurement.

[ataradov]

This measurement is quite challenging. The minimum output frequency of the PLL is 96 MHz, and the pad bandwidth is way lower. So you get pretty clean sine wave on the output if you put it directly on the pin. And dividing the clock cleans it up.

It is worth trying, but I would not expect great results.

[David Hess]

This measurement is quite challenging. The minimum output frequency of the PLL is 96 MHz, and the pad bandwidth is way lower. So you get pretty clean sine wave on the output if you put it directly on the pin. And dividing the clock cleans it up.

It is worth trying, but I would not expect great results.

Can you make the direct signal available on a pad?  Often ARM microcontrollers clock peripherals at a much lower frequency than the core.  Timer/counter measurements are not affected by this but core manipulation of the I/O ports sure is.

Since the jitter is currently being measured using a 100 Hz or 1 Hz signal, dividing it down before measuring the square wave output would be appropriate anyway.

[ataradov]

Can you make the direct signal available on a pad?

Yes, but it still will be 96 MHz going over 60 MHz pad at best. It will be a pure sine wave with slightly reduced amplitude. It is still probably good enough to measure the jitter.

Let me just grab a board and see what I get.

[PCB.Wiz]

I'm curious if there is some sort of user error here, as I was expecting better performance. One thing I'm suspecting is my choice of dev board (adafruit arduino clone - metro m4 express) which is equipped with an external 32.8 kHz crystal, rather than anything faster (and inconveniently the MCU's MHZ range XO pins are not exposed) - if this is the case, is the PLL frequency multiple of 3665 a bit too high to give good stability?

Yes, it will have worse jitter at lower PFD values.
If the PLL is an analog PLL, (as mentioned above) at 32kHz it only samples phase every 30us, which is a lot of hold time and low update bandwidth - all that means more jitter on the VCO.

[ataradov]

I used 12 MHz oscillator divided by 6 as a reference and configured PLL to run at 120 MHz. I have no way to observe 120 MHz, so I divided it by 12 before putting it out in a pin.  I see 20-40 ns of jitter compared to the reference clock. And occasionally it is much worse. But you can clearly see that it is locked with this configuration. With 32 kHz reference - not so much.

From what I can see it does work better with higher reference clock, and higher output frequency.

It is very hard to observe measure this with basic equipment I have here.

Here are captures over a minute or so of 2 MHz reference and 120 MHz divided by 60. First one is  right at the trigger, and the second one with a trigger 1 ms in the past. So it is locked and maintains the lock.

And one more thing to keep in mind - with 32 kHz reference and 120 MHz output, you will likely have fractional multiplier. And that can also contribute to jitter.

[ataradov]

If you do the same thing for 32 kHz reference, and divide 120 MHz by 3662, then the output is also perfectly locked and the jitter of that divided signal is 5 us.

[WatchfulEye]

Thanks for all the comments, especially to Ataradov for doing the experiment I wanted to do, but I don't have any spare oscillators with suitable output.

However, I was quite interested in this, so did a similar experiment - exporting the 32 kHz ref clock to a pin and then connecting it to the input capture pin of the timer. I then captured the times of the clock rising edge under a variety of PLL settings, and computed the frequency deviation over various averaging times.



The above image shows the fractional frequency deviation of the timer frequency (y-axis) as a function of averaging time in comparison with the 32 kHz PLL ref clock.

The main finding is that there is very little difference - other than slightly more time jitter with the lower frequencies, and a further slight penalty when using a fractional multiplier. There is a big difference from setting the wrong PLL loop filter (the discrepant example used a 46 kHz loop bandwidth, compared to 185 kHz for the others).

As a bouns, I was able to verify that the interval timer code works and doesn't lose events even logging 32k events per second. 

[WatchfulEye]

I thought I'd post an update, as I managed to obtain and get a 10 MHz oscillator working on my board. The pins necessary for crystal operation are not exposed, but the XIN pin can be used for a CMOS output oscillator, and this is exposed via the ICSP header. As I was feeling lucky, I bought an unknown oscillator off amazon - which turned out be sine output. After some trial and error, I found that this did in fact work with the MCU if AC coupled to the XIN pin, and setting XOSCCTRLn.XTALEN = 1 (presumably setting XTALEN enables a bias network internal to the MCU).

The experiment entailed inputting the 10 MHz clock, and routing the clock to a) a PLL and setting various ref frequency dividers, and multipliers to yield 200 MHz which was used to clock the input capture TC peripheral, and b) a /128 divider and routing the 78 kHz pulses to the input capture pin, and logging the timestamps, which could be used for analysis. The resulting analysis should represent the frequency stability taking into account the timer resolution and the PLL performance only.



As can be clearly seen, the higher the ref frequency, the better the PLL performance. I wasn't expecting 5 MHz to work, as it is significantly out of spec for the ref frequency, but it does work and gives better performance than 2.5 MHz. I don't know why the 1.25 MHz curve has a different shape to the others. I repeated this measurement several times, thinking it was an undetected data corruption issue (e.g. lost samples), but it is a consistent finding.

For context, the performance arising from the 5 MHz line represents a standard deviation of the timestamps of approx 0.8 clock cycles (4 ns). For the 39 kHz ref requency, the timestamp precision is about 2 orders of magnitude worse, unless measuring very short intervals (< 1 ms).

[ataradov]

PLL is sensitive to temperature. 5 MHz would likely not work at higher temperatures.

[PCB.Wiz]

PLL is sensitive to temperature. 5 MHz would likely not work at higher temperatures.

I think that is the PFD frequency, not the VCO frequency ?

[ataradov]

Yes, but it has its limits, and the maximum supported reference frequency is 3.2 MHz. This PLL is known to have locking issues at extreme temperatures with low reference frequency (< 1 MHz). I have not tried it with higher frequency, but I assume similar thing will happen. I have no idea what happens on a low level.

[peter-h]

Why would the PLL be temperature sensitive?

I would expect the on-chip clock multiplier to be a DPLL.

[ataradov]

Because it is a physical device implemented in silicon. Physical things have limitations.

[peter-h]

Is it a DPLL, or an analog PLL (a VCO, etc) implemented in silicon? A VCO has to be analog, at least.

[ataradov]

It is a digital PLL. There is still a VCO, of course, how else would it generate high frequency. The VCO is digitally controlled by a phase detector, which is also digital.