Electronics > Microcontrollers

Timing stability of MCU PLLs

(1/8) > >>

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.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod