SAMC with PLL frequency drift with temperature - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: February 01, 2024, 08:54:13 am
content: 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?

author: SeanB
author_rank: Super Contributor
timestamp: February 01, 2024, 08:58:59 am
content: 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.

author: Simon
author_rank: Unknown
timestamp: February 01, 2024, 09:19:20 am
content: Ah, so sitting next to motor drivers is probably not the best idea either.

author: SeanB
author_rank: Super Contributor
timestamp: February 01, 2024, 09:31:19 am
content: 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.

author: Simon
author_rank: Unknown
timestamp: February 01, 2024, 10:03:58 am
content: 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.

author: SeanB
author_rank: Super Contributor
timestamp: February 01, 2024, 10:24:53 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 01, 2024, 04:28:01 pm
content: 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.

author: brumbarchris
author_rank: Regular Contributor
timestamp: February 01, 2024, 07:56:29 pm
content: 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.81Now.. 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~FrequencyAnd 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

author: Simon
author_rank: Unknown
timestamp: February 01, 2024, 09:04:51 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 01, 2024, 09:56:08 pm
content: 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).

author: fourfathom
author_rank: Super Contributor
timestamp: February 01, 2024, 10:35:03 pm
content: 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: February 02, 2024, 03:53:28 am
content: Quote from: Simon on February 01, 2024, 08:54:13 amAs 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 02, 2024, 04:06:52 am
content: 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.

author: fourfathom
author_rank: Super Contributor
timestamp: February 02, 2024, 07:23:34 am
content: 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?

author: Simon
author_rank: Unknown
timestamp: February 02, 2024, 07:23:56 am
content: Quote from: ataradov on February 01, 2024, 09:56:08 pmI'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.

author: Simon
author_rank: Unknown
timestamp: February 02, 2024, 07:27:00 am
content: Quote from: fourfathom on February 02, 2024, 07:23:34 amJitter 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.

author: Simon
author_rank: Unknown
timestamp: February 02, 2024, 09:20:04 am
content: Code: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 oscillatorOSC32KCTRL->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 DPLLOSCCTRL->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; // 64MHzwhile((OSCCTRL->DPLLSYNCBUSY.reg & (1U << 2) ) == (1U << 2) ){// Waiting for the synchronization}// Selection of the DPLL EnableOSCCTRL->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}}

author: ataradov
author_rank: Super Contributor
timestamp: February 02, 2024, 04:42:59 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: February 02, 2024, 04:58:20 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: February 02, 2024, 05:43:49 pm
content: Quote from: brumbarchris on February 01, 2024, 07:56:29 pmThis 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?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: February 02, 2024, 06:37:48 pm
content: That’s a bit harsh.Watch crystalsaremuch 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

author: fourfathom
author_rank: Super Contributor
timestamp: February 02, 2024, 07:15:17 pm
content: 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=1706879563175https://www.ti.com/lit/an/slaa225a/slaa225a.pdf?ts=1706900861912A quote from the first link:QuoteThese 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.

author: Simon
author_rank: Unknown
timestamp: February 02, 2024, 10:27:59 pm
content: 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: February 03, 2024, 01:32:51 am
content: Quote from: Simon on February 02, 2024, 10:27:59 pmYes, 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=enQuote from: Simon on February 02, 2024, 10:27:59 pmI 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.

author: fourfathom
author_rank: Super Contributor
timestamp: February 03, 2024, 01:54:28 am
content: Quote from: Simon on February 02, 2024, 10:27:59 pmI 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?

author: Simon
author_rank: Unknown
timestamp: February 03, 2024, 08:47:38 am
content: right so my 25ppm 0.04ppm/C^2 is not so bad after all. All I need is to do CAN bus communication. This requires a clock stability of 1%, that is 10'000ppm.I can't say for sure that the chip was running from the internal RC oscillator but Ataradov's assessment of my code is pretty conclusive and the reaction of the chips to temperature very telling of an RC oscillator. When work have finished politicking for their boss from the US I can get down to some further testing which is worth it because it will salvage this first machine for further demo work while I work on the newer version.