XMEGA 32 MHz oscillator calibration using 32.768 kHz crystal

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using a spectrum analyzer on the power pins, I noticed that calibrating the oscillator using USB start of frame or a 32.768 kHz crystal both give a very accurate 48.0 MHz frequency (and corresponding EMI radiation...). However, if I don't wait for the crystal to be ready before setting the DFLLCTRL register, I get 49.8 MHz and it persists even when the crystal is ready. So it seems, the clocks logic faults and stays in that faulted state without calibration forever.

 

I prefer to skip the wait as it takes about a second for the crystal to stabilize and I want to start interacting with the user right away. I know I can be checking later in a an existing program loop and set the DFLLCTRL register there (when the osc is ready), but prefer to keep things encapsulated and was wondering if there is a more automatic or elegant way.

 

void clocks_init()
{
    // setup the crystal
    OSC.XOSCCTRL = OSC_X32KLPM_bm | OSC_XOSCSEL1_bm;
    OSC.CTRL = OSC_XOSCEN_bm;

 

    // setup the 48 MHz internal osc
    DFLLRC32M.CALA = nvm_read_production_signature_row(NVM_PTR(USBRCOSCA));
    DFLLRC32M.CALB = nvm_read_production_signature_row(NVM_PTR(USBRCOSC));

 

    uint16_t cal = (U32)48000000 / 1024;

    DFLLRC32M.COMP1 = LSB(cal);
    DFLLRC32M.COMP2 = MSB(cal);

    while(!(OSC.STATUS & OSC_XOSCRDY_bm)) { NOP; } // <------------ Removing this line make the clock permanently wrong, even after many seconds

    OSC.DFLLCTRL = OSC_RC32MCREF_XOSC32K_gc; // calibrate using the crystal

    OSC.CTRL |= OSC_RC32MEN_bm;

    DFLLRC32M.CTRL = DFLL_ENABLE_bm;

 

    while(!(OSC.STATUS & OSC_RC32MRDY_bm)) { NOP; }

 

    ccp_write_io((uint8_t *)&CLK.PSCTRL, CLK_PSADIV_2_gc | CLK_PSBCDIV_1_1_gc);
    ccp_write_io((uint8_t *)&CLK.USBCTRL, CLK_USBSRC_RC32M_gc | CLK_USBSEN_bm);
    ccp_write_io((uint8_t *)&CLK.CTRL, CLK_SCLKSEL_RC32M_gc);
}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

purple_beam wrote:

However, if I don't wait for the crystal to be ready before setting the DFLLCTRL register, I get 49.8 MHz and it persists even when the crystal is ready. So it seems, the clocks logic faults and stays in that faulted state without calibration forever.

Is that expected operation ? It seems less ideal to have a one-shot DLL calibrate, as that does not temperature track ?

 

purple_beam wrote:

I prefer to skip the wait as it takes about a second for the crystal to stabilize and I want to start interacting with the user right away. I know I can be checking later in a an existing program loop and set the DFLLCTRL register there (when the osc is ready), but prefer to keep things encapsulated and was wondering if there is a more automatic or elegant way.

There does not seem to be much choice - if the stability, or more likely level, is not enough, then you need to wait until it is enough.

If it is one-shot, you will need to time the snap-shot carefully.

That means the initial short time will be less well calibrated, until the xtal is ready.

 

Did you try varying the delay window ?  You may have enough 32kHz amplitude in less than a second.

Different crystals may have faster rise times too.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:
Different crystals may have faster rise times too.

Start-Up Time | Selecting and Testing 32 KHz Crystal Oscillators for AVR® Microcontrollers

[second paragraph]

Factors affecting the start-up time:

[ESR, Q, CL, Pierce oscillator drive current]

edit :

One Abracon 32KHz one micro-amp MEMS oscillator has a max start-up duration of 500ms hot.

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. Nov 21, 2020 - 12:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

edit :

One Abracon 32KHz one micro-amp MEMS oscillator has a max start-up duration of 500ms hot.

Yes, MEMS are slightly faster than Xtals to start/settle as the Q is lower.

I find SiT1566 is MAX 300ms and  ASTMTXK is typ 180ms and max 300ms  TA= -40°C to +60°C, valid output

Google finds some 32kHz parts specifying as low as 0.6ms startup, but at some Icc cost, so they may be using a higher kHz xtal and then dividing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:
Is that expected operation ? It seems less ideal to have a one-shot DLL calibrate, as that does not temperature track ?

 

What I was hoping for is that the clock starts running at approx. 48 MHz and once the crystal is ready, it automatically starts calibrating as long as that register is set. Hence my surprise that it didn't do that, and just never calibrated.

 

It appears that for USB start of frame calibration, you don't have to wait for several of these before enabling USBSOF calibration (but I might be wrong).

 

Thanks for the suggestion to look at different crystals.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

purple_beam wrote:
It appears that for USB start of frame calibration, you don't have to wait for several of these before enabling USBSOF calibration (but I might be wrong).
There's a defect with a work-around.

Help from the Atmel guys? | AVR Freaks

more :

Xmega lufa and usb 3.0 problem. | AVR Freaks

XMEGA DFLL USBSOF needs manual COMP tuning - why? | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller