This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC430F6137: Asymmetric and jumpy clock wave from 32768Hz crystal

Part Number: CC430F6137

Hi,

I installed the 32KHz crystal that came with the em-cc430f6137 boards and ran a simple program that:

Use XT1 as the source of ACLK

Use FLL to adjust the SMCLK frequency to 8MHZ

The code is attached and has been adapted from one of the examples provided by TI:

/* Configure CPU clock for 8MHz */

/* If clock settings are changed, remember to update BSP_TIMER_CLK_MHZ.
* Otherwise, all timer settings would be incorrect.
*/
// Initialize LFXT1
P5OUT &= 0x03;
P5DIR &= ~(BIT0 + BIT1);

P5SEL |= 0x03; // Select XT1
UCSCTL6 |= XCAP_3; // Internal load cap

// Loop until XT1 fault flag is cleared
do {
UCSCTL7 &= ~XT1LFOFFG; // Clear XT1 fault flags
} while (UCSCTL7 & XT1LFOFFG); // Test XT1 fault flag

UCSCTL0 = 0x0000; // Set lowest possible DCOx, MODx
UCSCTL1 = DCORSEL_5; // Select DCO range 16MHz operation
UCSCTL2 = FLLD_1 + 243; // Set DCO Multiplier for 8MHz
// (N + 1) * FLLRef = Fdco
// (243 + 1) * 32768 = 8MHz
// Set FLL Div = fDCOCLK/2
__bic_SR_register(SCG0); // Enable the FLL control loop

// Worst-case settling time for the DCO when the DCO range bits have been
// changed is n x 32 x 32 x f_MCLK / f_FLL_reference. See UCS chapter in 5xx
// UG for optimization.
// 32 x 32 x 8 MHz / 32,768 Hz = 250000 = MCLK cycles for DCO to settle
__delay_cycles(250000);

// Loop until XT1,XT2 & DCO fault flag is cleared
do {
UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG);

// Clear XT2,XT1,DCO fault flags
SFRIFG1 &= ~OFIFG; // Clear fault flags
} while (SFRIFG1 & OFIFG); // Test oscillator fault flag

UCSCTL6 &= ~(XT1DRIVE_3); // Xtal is now stable, reduce drive

I setup the ports in order to get the clock signals:

PMAPPWD =0x02D52;
P1MAP1 = PM_SMCLK;
P1MAP0 = PM_ACLK;
PMAPPWD = 0;
P1DIR |= BIT0 + BIT1;
P1SEL |= BIT0 + BIT1;

Now I visualized the clocks with a scope, here is the ACLK:

As you can see the frequency reported by the scope is 32.7690KHz.

I see some problems here:

1. The wave is not symmetric, please check the low part which is longer than the high part.

2. This is a static image but in real time the wave is not very steady, it has some fine jumps and the scope is reporting the frequency with highs and lows.

3. I suspect because of the instability of the base frequency, the high frequency (8MHz) is even more jumpy, see the attached video

I would like to have an opinion from an expert, is this the normal behavior or should I look for an error?

Thanks,

Dragos

  • By testing different scenarios I found that if I don't enable the FLL control loop, the wave becomes symmetric.
  • Hi Dragos,

    I recommend using external load capacitors alongside the external crystal instead of relying just on the internal ones. The waveform duty cycle is not much of a concern so long as it remains near 50% but the frequency should be precise for an external crystal. The crystal might be damaged or faulty, have you tried replacing it? You could also keep the default drive strength to see if that makes any difference. XT1 is the reference clock for the FLL so it makes sense that an unsteady crystal will not help stabilize the DCO sourcing (S)MCLK.

    Regards,
    Ryan
  • Hi,

    I put external capacitors and a new crystal-> same result. Same result also if I do not reduce the drive strength. I tested with more than one EM.. board (three) with the provided crystals and other brand also->same result. I can imagine that the problem comes from other things. Maybe the CC430 port output is not so stable in order to be able to make a quantitative measurement for crystal oscillation? Maybe the oscope itself cannot be used to do the thing?

    Thanks,

    Dragos

  • Hi Dragos,

    It's possible that the extra capacitance from the oscilloscope probe is causing issues with reading the clock signals. You might also try measuring the clocks on their native pins (P2.6/3.7 for ACLK/SMCLK, respectively) instead of using port mapping. I found a similar E2E thread which might be of some use and you can also refer to the crystal oscillator app note (SLAA322):

    e2e.ti.com/.../57370
    www.ti.com/.../slaa322c.pdf

    Regards,
    Ryan
  • The DCO modulator switches between two frequencies, so jitter is to be expected when you look at a DCO output.

    Is ACLK really configured for XT1 and not for the DCO? How have you configured UCSCTL4?
  • UCSCTL4 is not configured at all, see the source code above. It has default settings and the default source for ACLK is XT1.

  • The User's Guide says:

    If a fault is detected for the oscillator sourcing ACLK, ACLK is automatically switched to the DCO for its clock source (DCOCLKDIV) for all clock sources except XT1 LF mode. If ACLK is sourced from XT1 in LF mode, an oscillator fault causes ACLK to be automatically switched to the REFO for its clock source (REFOCLK).

    In theory, you are using XT1 in LF mode.

    In practice, you have observed that disabling the FLL affects the ACLK signal, so somehow you have a non-default source for ACLK. Please check the actual values of UCSCTL4 and UCSCTL6.

**Attention** This is a public forum