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.

MSP430F5419A: XT1 External Crystal doesn't control ACLK/MCLK/SMCLK

Part Number: MSP430F5419A

I have been trying unsuccessfully to setup the UCS to provide clocks from the XT! 12MHz crystal.  The crystal is oscillating at the correct frequency and the levels seem to match other designs which don't seem to have a problem.  The output clocks seem to be somehow always related to the DCO/FLL settings (anywhere from 2-18 MHz depending on setup) and not controlled by my initialization.  I have set the VCORE voltage leve to 2 at power up then do an chip initialization/setup.  The XT1HFOFFG and  XT1HFOFFG flags set at power on but I reset them after initialization and they stay reset.  The DCOFFG always remains set.  What is wrong with my setup??  Below are the values of all the UCS registers after initialization which provides me a clock (jittery) of about 17.7Mhz. 

UCSCTL0 0x1F00 UCS Control Register 0 [Memory Mapped] 

DCO4 1 DCO TAP Bit : 4
DCO3 1 DCO TAP Bit : 3
DCO2 1 DCO TAP Bit : 2
DCO1 1 DCO TAP Bit : 1
DCO0 1 DCO TAP Bit : 0
MOD4 0 Modulation Bit Counter Bit : 4
MOD3 0 Modulation Bit Counter Bit : 3
MOD2 0 Modulation Bit Counter Bit : 2
MOD1 0 Modulation Bit Counter Bit : 1
MOD0 0 Modulation Bit Counter Bit : 0

UCSCTL1 0x0050 UCS Control Register 1 [Memory Mapped]

DCORSEL 101 - DCORSEL_5 DCO Freq. Range Select Bit : 0
DISMOD 0 Disable Modulation

UCSCTL2 0x101F UCS Control Register 2 [Memory Mapped]

FLLD 001 - FLLD_1 Loop Divider Bit : 0
FLLN9 0 FLL Multipier Bit : 9
FLLN8 0 FLL Multipier Bit : 8
FLLN7 0 FLL Multipier Bit : 7
FLLN6 0 FLL Multipier Bit : 6
FLLN5 0 FLL Multipier Bit : 5
FLLN4 1 FLL Multipier Bit : 4
FLLN3 1 FLL Multipier Bit : 3
FLLN2 1 FLL Multipier Bit : 2
FLLN1 1 FLL Multipier Bit : 1
FLLN0 1 FLL Multipier Bit : 0


UCSCTL3 0x0000 UCS Control Register 3 [Memory Mapped]


SELREF 000 - SELREF_0 FLL Reference Clock Select Bit : 0
FLLREFDIV 000 - FLLREFDIV_0 Reference Divider Bit : 0


UCSCTL4 0x0000 UCS Control Register 4 [Memory Mapped]


SELA 000 - SELA_0 ACLK Source Select Bit: 0
SELS 000 - SELS_0 SMCLK Source Select Bit: 0
SELM 000 - SELM_0 MCLK Source Select Bit: 0


UCSCTL5 0x0000 UCS Control Register 5 [Memory Mapped]


DIVPA 000 - DIVPA_0 ACLK from Pin Divider Bit: 0
DIVA 000 - DIVA_0 ACLK Divider Bit: 0
DIVS 000 - DIVS_0 SMCLK Divider Bit: 0
DIVM 000 - DIVM_0 MCLK Divider Bit: 0

UCSCTL6 0x016C UCS Control Register 6 [Memory Mapped]

XT2DRIVE 00 - XT2DRIVE_0 XT2 Drive Level mode Bit 0
XT2BYPASS 0 XT2 bypass mode : 0: internal 1:sourced from external pin
XT2OFF 1 High Frequency Oscillator 2 (XT2) disable
XT1DRIVE 01 - XT1DRIVE_1 XT1 Drive Level mode Bit 0
XTS 1 1: Selects high-freq. oscillator
XT1BYPASS 0 XT1 bypass mode : 0: internal 1:sourced from external pin
XCAP 11 - XCAP_3 XIN/XOUT Cap Bit: 0
SMCLKOFF 0 SMCLK Off
XT1OFF 0 High Frequency Oscillator 1 (XT1) disable

UCSCTL7 0x0301 UCS Control Register 7 [Memory Mapped]

XT2OFFG 0 High Frequency Oscillator 2 Fault Flag
XT1HFOFFG 0 XT1 High Frequency Oscillator 1 Fault Flag
XT1LFOFFG 0 XT1 Low Frequency Oscillator Fault Flag
DCOFFG 1 DCO Fault Flag

UCSCTL8 0x0707 UCS Control Register 8 [Memory Mapped]

MODOSCREQEN 0 MODOSC Clock Request Enable
SMCLKREQEN 1 SMCLK Clock Request Enable
MCLKREQEN 1 MCLK Clock Request Enable
ACLKREQEN 1 ACLK Clock Request Enable



  • Hi Roger,

    I see you've spent your time on the register settings. If I understood you correctly your XT1 is working as expected.

    Could you confirm that your issues is that the MCLK, SMCLK and ACLK seem to not run from XT1? Is this what you mean by output clocks? Did you confirm that by measuring the clock frequency at an output pin or by debugging the register settings?

    In which operating mode do you see the unexpected clock settings?

    Thanks for the clarification and best regards,
    Britta
  • I observed the MCLK on P2.0 and ACLK on P2.6 with an oscilloscope. Both outputs are are the same wrong frequency of about 17.8MHz with a 12Mhz crystal oscillating at the correct freq. I actually observe the SMCLK output but I assume it would be the same. The processor is in run mode, no low power have been coded yet.
  • Hi Roger,

    would you mind sharing the part of the code with me where you actually configure the clocks? From what you've pasted before your understanding seems to be correct but there might be something unintended in your code.
    I'd only need the part with the clock settings to have a look at.

    Thanks and best regards,
    Britta
  • I normally don't do anything with the clocks except in the chip initialization routine.  I searched all my modules for anything with "UCS" and found no entries other than the following.  I do set up several uart channels with baud rates etc but I can't imagine how that would impact the core clock functionality.  There are 4 instructions in the initialization routine which are:

    UCSCTL1 = 0x0050; //TESTING
    
    UCSCTL4 &=~SELS_4 + ~SELM_4;          // ALL CLOCKS TO XT1CLK
    
    UCSCTL6 =0x016C;
    
    UCSCTL7 &= ~XT1HFOFFG;      // Clears any clock startup faults doesn't seem to work.
    

    and then in the main.c I added a couple of line to debug this issue:

    UCSCTL7 = 0; //TESTING RESET OF FLAG
    
    UCSCTL3 = 0;
    

    Since the clocks seem to be using the DCO/fLL, I a guessing it is because the processor thinks the crystals are not correct.  The flags are set after the initialization routine even though I clear them as part of the initialization at the end.  As you can see I added a clear back in the main.c after the initialization call and after that execution, they stay cleared.    I ordered some different crystals and will give them a try in a day or two.  

  • Britta:  I replaced the 12Mhz crystal with a different vendors part with no effect or change.  There must be something in my setup that is wrong but I cannot understand what it could be.  Do you see anything and or have anything else I can try.  I have been working with the UCB0 I2C interface to debug some of my interfaces while this problem remains to be solved.  I don't know if this could be a clue but in order to get a clock in the UCB0 channel, I had to select SMCLK as the source.  I also changed the DCORSEL selection from DCORSEL_5 to _4 so that my clock frequency was about 10MHZ for testing. ..  Any suggestions at this point?

  • Hi Roger,

    I've gone through the provided data again.

    You run the XT1 in high-frequency mode, could you quickly verify which frequency range you want to set? You set it to 01b (range from 8MHz to 16MHz), correct?

    How did you verify that your crystal acually puts out the correct frequency? You might try our MSP430 32-kHz Crystal Oscillators Application Report, which gives valuable trouble-shooting hints for both low- and high-frequency oscillators.

    To your above post:

    Is your SMCLK setting working then? did you try modifying it with different pre-dividers and it works?

    You said you clear the XT1HFOFFG and it reamins cleared, true? Did you check section 5.2.12 in the MSP430x5xx and MSP430x6xx Family User's Guide to see if any of the described UCS Module Fail-Safe Operation indications occur in your system? It could be that a fault is detected and all your clocks are automatically sourced from DCO, does this match what you see?

    Please check the indicated options above and let me know if any of this helps you to move forward.

    Thanks and best regards,

    Britta

  • Britta: Both XT1HFOFFG AND XT1LFOFFG along with DCOFFG are set after initialization. After that, writing 0 to the register results in only DCOFFG remaining set probably because the DCO is at 31. Without any further changes to the UCS module settings, both XT1 flags remain reset. I have done many designs using the XT2 crystal connections, but this is my first using XT1 (probably my last). The general literature seems to indicate this is intended for low frequency oscillators for low power operation. I reviewed the sections you mentioned and nothing seemed to stand out as an indicator of what is going on. I am not totally clear if the processor overrides for example the SELA_x settings or not. To try to determine where the clocks are coming from I performed several tests as follows. My conclusion is that somehow my clock is coming from the internal REFO oscillator with various multipliers. My nice 12Mhz sine-wave (measured with scope probe at the crystal) external crystal somehow is not translated out. These quartz 12Mhz crystal (fundamental frequency mode) devices are generally very tolerant of changes in load capacitance etc. My best guess is that it initially goes in fail safe mode and stays there even after the error flags are reset.

    With all the settings as described in my original post except that DCORSEL is set to __4 range. Changing the SELA_0 setting gives the following ACLK output results. 0=9.0Mhz, 1=9.3kHz, 2=32.5kHz, 3=18Mhz, 4=18Mhz and 5=9Mhz and this 5 setting also sets the X2OFFG flag.
    With SELA_0, I changed the SELREF clock settings withe following ACLK output results. SELREF_0=9MHz, 2=1.1Mhz, 7=1.1Mhz. With SELREF=7 I then changed SELA settings with the following results: 0=1.1Mhz, 1=9.3kHz, 3 and 4 = no clock output. (Note the 1.1Mhz freq is about 31 times the 32.765 kHz internal crystal. )

    Another test was to set XT1OFF to 1 with no effect on my 9Mhz clock signal. Setting X1BYPASS to 1 changes the output freq from 9Mhz to 1.1Mhz.

    I have a 100 pin demo board and installed several 12Mhz crystals in it with no different results than I measured with my breadboard design.
    Some other observations are: OFIFG is set and will not reset. OFIE is 0 and I am not sure what the hardware/my software should do if it would be enabled. This may just be related to the DCO error flag remaining set. One last question: Is there a maximum crystal load capacitance specified?? I saw a reference to 18pf but it wasn't a specification. My crystal load capacitance is specified at 20pf (and I have two paralleled 33pF caps external to derive that) .
    My next step is probably going to be scrapping the XT1 oscillator and try switching to the x2 oscillator with a bunch of cuts and jumpers!!
  • Hi Roger,

    just for my confirmation:

    Did you implement any code checking for all the oscillator fault flags to stay cleared:

      // 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

    This will help to rule out that there actuall still is an issue with the crystal.

    The section I indicated before on the Fail-safe operation indicates that the clocks will be switched in case fault is detected on the according clock source (for example if XT1 in HF mode supplies clock to ACLK, then, if XT1 is not working properly, ACLK will automatically be switched to REFO without changing the SELA settings though). From what you've indicated that seems to be what's happening.

    Thus my recommendation would be to again check the crystal functionality (for example with the provided code on top).

    To your question:

    We don't specify a maximum crystal load capacitance, but we encourage "Oscillation allowance is based on a safety factor of 5 for recommended crystals."

    Hope this helps to get down to the problem.

    Best regards,

    Britta

  • Hi,

    as I didn't hear back from you in a while I assume that your issue has been solved.
    Please go ahead and verify the given answer to also help other users that might run into the same issue.

    Note that I'll go ahead and close this thread in the next couple of days if I don't hear back from you. Replying to the thread will re-open it if necessary at some point.

    Best regards,
    Britta
  • Britta:  I have been pulled off this job for a bit and probably won't get back to it for another week.  I cant loop on the error flags because they remain set.  I tried to setup the fll/dco for about 10Mhz running of the reflo internal oscillator but couldn't get it to reset the dco error flag or the interrupt flag which seem to remain set no matter what I do.  The other 2 xtal oscillator flags reset and stay reset.  If you need to close the case you can, I can always open another if with further trial and error I can't make any progress.

    Roger

  • Please note that the clock module reports errors for any clock source that is used by any clock (ACLK, MCLK, SMCLK, or the DCO FLL reference) or not disabled with XT1OFF/XT2OFF. If you are not using some source, ensure that it is not configured anywhere.

    Clock initialization requires many fiddly details. Better start with one of the code examples, check that it works, and then make changes as needed.

  • Hi Roger,

    I don't know if you had time to follow Clemens' guidance on this issue but this would be a good starting point for you.
    Besides, the explanation on the error flags was what I tried to emphasize on also.

    I'll go ahead and close this thread for now. Please re-open it or post a new thread in case you have time to re-look at this and find it still doesn't solve the issue.

    Best regards,
    Britta

**Attention** This is a public forum