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.

MSP430F5508 clocking from external clock at xt2in

Other Parts Discussed in Thread: MSP430F5508

Hello to all,

i am facing a weird problem. I have build a can interface box with an MSP430F5508. As the external CAN-Controller supplies a 16 MHz clock signal, i decided to connect this clock signal to XT2IN and feed MCLK and SMCLK from it. This is what i have done so far:

P5SEL |= 4; // P5.2 (XT2IN), select alternative function XT2 for P52 and P5.3

P5DIR &= ~4; // may not be necessary

SetVCore(PMMCOREV_2); // core voltage has to be adjusted to run at 16 MHz

UCSCTL6 |= XT2BYPASS; // XT2BYPASS = 1 and XT2OFF select external clock on input pin

UCSCTL4 = SELA__XT2CLK|SELS__XT2CLK|SELM__XT2CLK;
UCSCTL5 = DIVA_0|DIVS_0|DIVM_0;

To make it switch over to the right clock source, i had to:

UCSCTL7 &= ~XT2OFFG;
SFRIFG1 &= ~OFIFG;

Why do i have to clear the bit in SFRIFG1?

cheers

Gunther

  • Gunther said:
    Why do i have to clear the bit in SFRIFG1?

    I don't think you have to. Only if you want to get an interrupt (NMI) if an oscillator fails.

    The OFFG bits, however, need to be cleared to have the clocks switched to XT2. (with the exception of DCOFFG as the DCO will always operate, and this bit rather indicates an FLL fault than an oscillator fault)

  • I've tried with and without clearing the bit in SFRIFG1.

    If i don't clear it, MCLK and SMCLK were sourced by DCOCLK. The clock system doesn't switch over.

    cheers

    Gunther

  • Interesting.

    This is strange.

    If OFIFG switches MCLK and SMCLK to DCO, even if XT2OFFG is clear, it would mean that even a DCO fault (which actually isn't a fault) would switch them back to DCO. Which would be plain stupid.

    However, one of the notes seems to shed some light on this:

    "Please note that as long as a fault condition still exists, the OFIFG remains set. The application must take special care when clearing the OFIFG signal. If no fault condition remains when the OFIFG signal is cleared, the clock logic switches back to the original user settings prior to the fault condition."

    So if you switched MCLK/SMCLK to XT2 before the XT2OFFG bit was clear, the clocks are switched back to DCO (of course), but will not automatically switch back to XT2 once stable, unlessyou clear OFIFG.

    So I guess, if you first wait for XT2 (XT2OFFG clear) and then switch MCLK/SMCLK to XT2, the clocks will switch, even if OFIFG is still set.
    I further guess, if you try to clear OFIFG but it remains set due to XT1OFFG or DCOFFG still set, the mere attempt to clear it will switch MCLK and SMCLK back to XT2 (provided that XT2OFFG is clear).
    So OFIFG mos tlikely won't prohibit switching MCLK/SMCLK to XT2 if XT2OFFG is clear, but clearing (or tring to clear) OFIFG will undo a previous fallback.

    To be verified...

  • Gunther said:
    Why do i have to clear the bit in SFRIFG1?

    It's there in case you want to coordinate or synchronize the switch over.

    The XT2OFFG bit lets you evaluate the crystal or external clock.  If you clear XT2OFFG and read it back, you may find that it is still set.  In that case, the XT2 logic isn't yet satisfied with XT2CLK.  If you read it back and find that you successfully cleared it, then the crystal or clock is working and the XT2 logic is satisfied.

    After finding that the clock is OK, you may want to coordinate with another system or synchronize to some kind of periodic event etc etc before you actually switch to XT2.  Then you clear OFIFG to make the switch.

    So it's just extra flexibility that is probably not used very often.

    Jeff

**Attention** This is a public forum