SAMC with PLL frequency drift with temperature

[Simon]

I set up my boards with a SAMC micro controller with a 32.768 kHz crystal and used the PLL to get that to 48MHz. It seems that the boards are quite sensitive to temperature. I need to do more testing as I have only checked a 20kHz PWM that I generate from the 48MHz clock which includes both crystal and PLL. I should also get some output from the crystal directly to verify better.

I got the frequency to shift though by simply putting my finger on the micro controller. My new design no longer uses the PLL so it may be mute now but I would still like to know. Is this normal of PLL's in general or is it something specific about the SAMC?

I suppose the best question to ask is, is using a PLL in a micro controller a good idea when I need an accurate clock?

[SeanB]

Probably 50Hz is being injected via the capacitance between your finger and internal high impedance nodes of the PLL, likely the VCO side, that modulates it. Not normally an issue if the device is in a case, but you often enough found old IC's with noise issues that had it fixed by the application of a copper tape to the top surface, and a soldered wire from that to the ground plane, or the IC ground pin on DIP parts.

[Simon]

Ah, so sitting next to motor drivers is probably not the best idea either.

[SeanB]

Probably not, though you could isolate the PLL with it's own ground plane, and route high current away from it. Might also be worth to make a small PCB, with simple ground plane, and 4 pins in the corners, connected to the local ground plane of the PLL chip, and put it on top as a shield. Seen that often enough as a easy way to shield sensitive parts, and for SMPS units to reduce radiated EMI without going to a metal case around it.

[Simon]

No the micro controller (with PLL inside) is on it's own PCB, but the PCB is near a motor driver which may be emitting some noise.

[SeanB]

Ground plane on the side facing motor drive, should be fine. Wires draped across PLL put the shield, you can always just put the 4 holes for the shield there, and not populate it, only if you have RF interference, but as long as the wires and such are not draped across the chip should be fine with a small distance between them.

[ataradov]

Show exact configuration of all the involved components. The only way I can see PLL being sensitive to the finger touch is if internal RC oscillator is used as a reference.

[brumbarchris]

Note that 32.768kHz crystals are rather poor in terms of tolerance and stability vs. temperature, when compared against crystals in MHz range.

I am sure your crystal is affected by a temperature curve similar to one of these:

https://www.google.com/search?client=ms-android-samsung-ss&sca_esv=9ace15581ead379a&q=32.768+khz+crystal&tbm=isch&source=lnms&prmd=sivbnmtz&sa=X&ved=2ahUKEwi_gJuT84qEAxUphv0HHZMaAkYQ0pQJegQIDRAB&biw=384&bih=718&dpr=2.81

Now..  a small drift at 32kHz, multiplied with the multiplication coefficient of the PLL...could well result in significant drift of the expected frequency at the output of the PLL (although, being sensitive to the finger touch sounds a bit extreme...).

Compare this stability to what you get from 16MHz mainstream crystals, for instance:

https://www.mouser.ch/c/passive-components/frequency-control-timing-devices/crystals/?frequency=16%20MHz&frequency%20stability=10%20PPM&m=ABRACON~~Citizen%7C~Epson%7C~KYOCERA%20AVX%7C~Murata~~NDK&tolerance=10%20PPM&rp=passive-components%2Ffrequency-control-timing-devices%2Fcrystals%7C~Manufacturer%7C~Frequency

And keep in mind that when using a MHz crystal with the PLL, overall multiplication factor of the PLL itself is considerably lower than in the case when it is fed by a crystal in the kHz range.

Regards,
Cristian

[Simon]

I thought the 32kHz crystals were more accurate due to the crystal being larger as the frequency is lower. They were chosen precisely because 2^15 is the lower power of 2 frequency that a human cannot hear and this makes them ideal in clocks!

It is possible that the clock system is using the internal 32kHz oscillator, I need to do some digging.

[ataradov]

There is absolutely no way you can heat a crystal with your finger to the point where frequency drifts in a noticeable way. But I don't see what it has to do with being able to hear it if you are instantly PLL'ing it to 48 MHz (and actually 96 MHz, since this is the VCO frequency).

[fourfathom]

How much shift are we talking about?  A 32KHz crystal typically has an accuracy of 20ppm and a temperature stability of about 0.03 ppm per (degrees C temp change squared).  The effect of a few degrees temperature change can easily be measured with commonly-available equipment.  For an audio tone the minimum noticeable frequency shift is about 6000 ppm, so your ears aren't going to tell you much. 

Also, a (for example) 1 ppm shift after multiplying with a PLL is still a 1 ppm shift, but of course the absolute frequency change is multiplied.

The internal 32 KHz oscillator will be much less stable than even a poor crystal.

[PCB.Wiz]

I suppose the best question to ask is, is using a PLL in a micro controller a good idea when I need an accurate clock?

As always, it depends.  What does 'accurate' mean ?

Most MCU's working against a 32kHz crystal, use a digital lock loop, rather than an analog Phase locked loop. (It's simpler and the PFD frequency is very low at 32kHz for analog charge pumps).

Exactly how they do that varies, but they usually have a granularity of the Trim step size.
Some use a GoUP/GoDn correction that always jitters about the correct crystal average.

I've seen others that claim to pick a correction trim and only change when that exceeds some error.
That has less jitter, but poorer long term precision.

You should be able to check by outputting a nominal 32.768 toggle pin, and check the jitter and freq.

[ataradov]

FDPLL is characterized in the datasheet. The worst case period jitter is 8% with fIN = 32 kHz, fOUT = 96 MHz. And it is 3% at 48 MHz output. It is generally better if only integer multiplication is used. Fractional part adds more noise.

There is a loop filter bandwidth setting, which may improve results in specific cases. But generally, it is sufficient for most practical uses. And if a really clean clock is necessary, it should be supplied from the outside.

[fourfathom]

Is Simon's problem jitter or drift?  unless the PLL (or FLL, or some digital correction loop) is losing synchronization then any long-term drift should be traceable to the reference oscillator.  Jitter is a completely different animal.  I enjoy discussing oscillator and clock characteristics in general, but what was the specific problem?

[Simon]

But I don't see what it has to do with being able to hear it if you are instantly PLL'ing it to 48 MHz (and actually 96 MHz, since this is the VCO frequency).

I'm referring to the reasons these are "clock crystals" originally devised as the most accurate compromise possible. the frequency is 2^15, as a power of 2 it can be divided with the simplest IC design, as it is as low as possible cutting the crystal is easier given the larger size. I assume there is a fixed error of some sort in the cutting process that becomes less in ppm terms with a bigger crystal. but if they went lower for a bigger more accurate crystal people may hear the crystal as it would have been 16kHz or 8 kHz.

So knowing that I don't believe what brumbarchris said about stability of the crystal. It's more likely that I have somehow ended up with the RC 32 kHz as you say. I have resolved this already by using an external 48MHz clock generator.

[Simon]

Is Simon's problem jitter or drift?  unless the PLL (or FLL, or some digital correction loop) is losing synchronization then any long-term drift should be traceable to the reference oscillator.  Jitter is a completely different animal.  I enjoy discussing oscillator and clock characteristics in general, but what was the specific problem?

Jitter is also possible, my 20kHz PWM that is generated from the 48MHz from the PLL is not exactly stable. Hence between one thing and another I have opted for an external 48MHz clock generator. I often had the ADC's fail to work unless I lowered their clock by increasing the prescaler, so maybe jitter or other instability that by division is taken out or at a lower frequency is less of an issue.

[Simon]

Code: [Select]

static void OSC32KCTRL_Initialize(void)
{
    /****************** XOSC32K initialization  ******************************/

OSC32KCTRL->XOSC32K.reg = 0x0 << 8  | 0x1 << 4 | 0x1 << 3 | 0x1 << 2 | 0x1 << 1 ;

OSC32KCTRL->CFDCTRL.reg |= 0x1 << 1 | 0x1 << 0 ;

while(!((OSC32KCTRL->STATUS.reg & (0x1 << 0)) == (0x1 << 0))) // XOSC32RDY
{
// Waiting for the XOSC32K Ready state
}

    /****************** OSC32K Initialization  ******************************/

    uint32_t calibValue = (((*(uint32_t*)0x806020UL) >> 12 ) & 0x7FUL);

// Configure 32K RC oscillator
OSC32KCTRL->OSC32K.reg = calibValue << 16 | OSC32KCTRL_OSC32K_STARTUP(0UL) | 0x1 << 3 | 0x1 << 2 | 0x1 << 1 ;

while(!((OSC32KCTRL->STATUS.reg & (0x1 << 1) ) == (0x1 << 1) ))
{
// Waiting for the OSC32K Ready state
}

OSC32KCTRL->RTCCTRL.reg = 0x4 ;

/************************************ RTC *********************************/

OSC32KCTRL->RTCCTRL.bit.RTCSEL = 0x5 ;
}



static void FDPLL_Initialize(void)
{

    // ****************** DPLL Initialization  *********************************

    // Configure DPLL   
    OSCCTRL->DPLLCTRLB.reg = 1U << 12 | 0UL << 8| 0UL << 4 | 0UL << 0 ;
OSCCTRL->DPLLRATIO.reg = 0U << 16 | 1464U << 0; // 48MHz
//OSCCTRL->DPLLRATIO.reg = 0UL << 16 | 1952UL << 0; // 64MHz

while((OSCCTRL->DPLLSYNCBUSY.reg & (1U << 2) ) == (1U << 2) )
    {
        // Waiting for the synchronization
    }

    // Selection of the DPLL Enable
    OSCCTRL->DPLLCTRLA.reg = (uint8_t)(1U << 1 );

while((OSCCTRL->DPLLSYNCBUSY.reg & (1U << 1) ) == (1U << 1) )
    {
        // Waiting for the DPLL enable synchronization
    }

while((OSCCTRL->DPLLSTATUS.reg &  (1U << 1)  ) != (1U << 1) )
    {
        // Waiting for the Ready state
    }

}


[ataradov]

You are configuring 0 startup time, which is likely not correct. There is no crystal that starts in no time.

You then configure clock failure detect and automatic switch. Have you verified that the oscillator is actually running and this switch did not trip?

You are setting lock bypass on the PLL, so it will output something regardless of whether it is locked or not. Was this done to workaround it not providing any output? Have you verified that PLL is locked?

I would do this one step at a time. First all disable all those failure detects and lock bypasses. Then output 32 kHz on the GCLK [ x ] pin and verify that oscillator is running, do the measurements with temperature variations. Once this is working, connect it to the PLL and do the rest of the measurements.

Also, this code does not show that timers and the rest of the system actually use this PLL as a clock source. Verify that as well, you may be running parts of it on the default OSC48M, which is very sensitive to the temperature.

[Simon]

The clocks are configured to all come from the PLL, I think I did notice at one point that the ADC worked from the internal RC clock but not the PLL, this is when I decided to use an external generator. I am running a new board today with the 32kHz crystal. This clocks the RTC that generates all of the system timings. I did already on this disable the clock switch and the board has always run, so maybe it was a false clock switchover. With the PLL, I understand that there is a bug where it may falsely think the output is wrong so I thought I was just ignoring all that and had to just hope. This is why I went to the external clock anyway.

As soon as I get a moment I'll try revisiting the same boards with different settings, we have our American group MD next week so won't be for a while.

[Simon]

Note that 32.768kHz crystals are rather poor in terms of tolerance and stability vs. temperature, when compared against crystals in MHz range.

I am sure your crystal is affected by a temperature curve similar to one of these:

https://www.google.com/search?client=ms-android-samsung-ss&sca_esv=9ace15581ead379a&q=32.768+khz+crystal&tbm=isch&source=lnms&prmd=sivbnmtz&sa=X&ved=2ahUKEwi_gJuT84qEAxUphv0HHZMaAkYQ0pQJegQIDRAB&biw=384&bih=718&dpr=2.81

Now..  a small drift at 32kHz, multiplied with the multiplication coefficient of the PLL...could well result in significant drift of the expected frequency at the output of the PLL (although, being sensitive to the finger touch sounds a bit extreme...).

Compare this stability to what you get from 16MHz mainstream crystals, for instance:

https://www.mouser.ch/c/passive-components/frequency-control-timing-devices/crystals/?frequency=16%20MHz&frequency%20stability=10%20PPM&m=ABRACON~~Citizen%7C~Epson%7C~KYOCERA%20AVX%7C~Murata~~NDK&tolerance=10%20PPM&rp=passive-components%2Ffrequency-control-timing-devices%2Fcrystals%7C~Manufacturer%7C~Frequency

And keep in mind that when using a MHz crystal with the PLL, overall multiplication factor of the PLL itself is considerably lower than in the case when it is fed by a crystal in the kHz range.

Regards,
Cristian

This post is complete bullshit! you just put a link to an image search claiming that these crystals are bad. Why do you have a grudge against watch crystals? or do you just like to throw misinformation out there?

[PCB.Wiz]

That’s a bit harsh.
Watch crystals are much more temperate sensitive than MHz cut crystals.
It’s simple physics.

They are low frequency and low power, but there is a compromise.

There is a large jump from kHz to MHz choices, but some interesting options are appearing in 32kHz oscillator modules that use higher freq, more stable cut crystals and divide.

They do not get sub-uA but some are low-uA

[fourfathom]

PCB.Wiz is correct.  Here are some links to Texas Instruments app notes about these crystals and oscillators:
https://www.ti.com/lit/an/slaa322d/slaa322d.pdf?ts=1706879563175
https://www.ti.com/lit/an/slaa225a/slaa225a.pdf?ts=1706900861912

A quote from the first link:

The amount of the frequency variation due to temperature depends very much on the crystal cut and the
crystal shape. In comparison to some other crystal cuts, 32-kHz tuning-fork crystals exhibit a relative high
frequency drift over temperature. Figure 6 shows the typical frequency deviation of a 0-ppm tuning-fork
crystal over temperature. The ±ppm tolerance value, given in the crystal data sheet, shifts the graph of the
tuning-fork crystal up and down.

These crystals usually use an "XY" cut, required for low-frequency resonance in a physically small crystal.  Crystals in the MHz range are usually "AT" cut, which is much more stable.

But none of this is likely to have anything to do with Simon's problem.

[Simon]

My watch crystal is 25 ppm with 0.04 ppm/C^2, I don't see why he puts up a link to an image search as "evidence", all he had to do was put a link to actual products like the mouser search he put after.

The 48MHz clock generator I chose is 100ppm and gives no temperature information. Maybe that is included in the 100ppm? so if these watch crystals are so bad why are we using them or is it just power consumption?

The frequency shifted when I put my finger on the micro controller not the crystal.

[PCB.Wiz]

My watch crystal is 25 ppm with 0.04 ppm/C^2, I don't see why he puts up a link to an image search as "evidence", all he had to do was put a link to actual products like the mouser search he put after.

The 48MHz clock generator I chose is 100ppm and gives no temperature information. Maybe that is included in the 100ppm?

Yes, 100ppm would be Temp/voltage/load and maybe even aging too.

Epson have good data showing the MHz/Temp curves, and how they vary with target temperature span (and thus cut chosen)

https://support.epson.biz/td/api/doc_check.php?dl=app_SG2016CAN&lang=en

so if these watch crystals are so bad why are we using them or is it just power consumption?

I would not call them 'so bad', they have a definite price/power/ppm point, for many instances they are 'good enough'.

Many modern RTCs have a crystal offset/aging trim register, which can be used to remove the fixed offset errors, leaving just temperature and aging.

The parabola is somewhat predictable, so you can buy TXCO, or do a rough TCXO improvement yourself, with a MCU with temperature sensor.

From the numbers given above, in #12, you did the right thing moving to an external oscillator.

[fourfathom]

The frequency shifted when I put my finger on the micro controller not the crystal.

I know you suspected that the uC was actually using the internal oscillator, and not the 32KHz crystal.  If so, that would explain this.  I suppose it doesn't matter any more, but have you determined if that was the case?