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.

XT1 turning OFF in LPM3 (IF XT2 is OFF)

Other Parts Discussed in Thread: MSP430F6638

Hi,

I have exact same issue as this ( https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/131760

I am using MSP430F6638 controller. As per the Datasheet ACLK and the Source clock from which ACLK is derived from will NOT be turned OFF in LPM3 (Deep SLeep).

But in my case, As soon as i enter the LPM3, XT1 stops oscillating.

The above mentioned scenario is occuring ONLY when the XT2 crystal is being Turned OFF. And if XT2 is NOT turned OFF and then enter to LPM3, The XT1 remains Oscillating.

How I am configuring the Clocks

  P3SEL |= BIT4; // SMCLK
  P3DIR |= BIT4;

  P7SEL |= 0x0C; // P7.3,2 -> XT2OUT, XT2IN

  // Unlock XT1 pins for operation
  while(BAKCTL & LOCKBAK)
  {
    BAKCTL &= ~(LOCKBAK);
  }

  // From XT2 = 16 Mhz
  UCSCTL6 |= XCAP_2; // Fz 120216: Internal load cap (CAP Value + 2)/2 = 8.5pF (Refer Datasheet)
  UCSCTL6 &= ~(XT1DRIVE1 | XT1DRIVE0 | XT2DRIVE1);
  UCSCTL6 |= (XT2DRIVE0);
  UCSCTL6 &= ~XT2OFF;       // Set XT2 On
  UCSCTL6 &= ~XT1OFF;       // Set XT1 On
  UCSCTL3 = 0x0021; // FLL : REFOCLK and divby2

  do
  {
    UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG); // Clear XT1 fault flags
  }while(UCSCTL7 & (XT2OFFG + XT1LFOFFG)); // Test XT1 fault flag

  __bis_SR_register(SCG0); // Disable the FLL control loop

  UCSCTL0 = 0x1F00; //Range
  UCSCTL1 = 0x50; //Range
  UCSCTL2 = 0x1138; // MCLK : 5 Mhz

  _delay_ms(100);

  // Clock Source Selection :
  UCSCTL4 = 0x0054;     // ACLK : XT1CLK; SMCLK : XT2CLK; MCLK : DCOCLKDIV
  UCSCTL5 |= DIVS1;     // SMCLK div by 4 (4 Mhz)

  UCSCTL3 |= 0x0021;      // FLLRef : REF0; FLLRef/2 => MCLK = 5Mhz

  // Enable the FLL control loop
  __bic_SR_register(SCG0);

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

    SFRIFG1 &= ~OFIFG; // Clear fault flags

  }while(SFRIFG1 & OFIFG); // Test oscillator fault flag

HOW I am turing OFF the XT2 :

UCSCTL6 |= (SMCLKOFF);
_delay_ms(10);
UCSCTL6 |= (XT2OFF);

Crystal Sources

XT1 : 32.768 Khz

XT2 : 16 Mhz

Peripherals Depending on ACLK (and hence on XT1)

UART baud generation

Watch Dog Interrupt

Once I enter the LPM3, I expect the WDT timer to wake the controller from Deep Sleep, but observed that XT1 gets turned OFF immediately as i enter the LPM3 ( also tried LPM0) and hence the controller never wakes up from Sleep.

What I already Made Sure :

I made sure that the Interrupts are working (while in LPM3)

Working Fine in the following Scenarios

  1. When USB is connected ( XT2 is active )

  2. XT2 NOT Turned OFF

  3. Debugger/Emulator Connected ( I understand that LPM doesnt entirely work with Emulator connected)

Tried this page : https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/131760

Also tried the ERRATA UCS11 error. (I assume this is not needed while turning OFF XT2)

Thanks in Advance.

  • Crystal used on the board has Load Capacitance of 12.5 pF.
    if XT1 Capacitors are 15pF each , will that have any impact other than the frequency change ?
  • Hi Feroze,

    What are you trying to set your core frequency to? The initialization of UCSCTL0, UCSCTL1, and UCSCTL2 lead me to believe that the DCO and DCORSEL bits are setting a DCO frequency of above 12 MHz. At this frequency it is essential that PMMCOREVx is raised to a level of at least 1 according to Figure 5-1 of the device datasheet. You can view example msp430f66xx_UCS_03.c for a demonstration of how to do this. Furthermore, please try to run example msp430f66xx_UCS_07.c with the following changes:

    1. XT2DRIVE set to 1h inside of UCSCTL6 since you are using a 12 MHz external oscillator.
    2. Do not set the internal load cap bits (XCAP) inside of UCSCTL6 because you use external load caps.
    3. Turn off XT2 and enter LPM3 during the while loop, probing P1.0 with an oscilloscope to see if ACLK stops.

    If the issue persists then the problem most likely has to do with your crystal hardware, if not then the clock initialization is probably at fault.

    Regards,
    Ryan
  • Ryan Brown1 said:
    Hi Feroze,

    What are you trying to set your core frequency to? The initialization of UCSCTL0, UCSCTL1, and UCSCTL2 lead me to believe that the DCO and DCORSEL bits are setting a DCO frequency of above 12 MHz. At this frequency it is essential that PMMCOREVx is raised to a level of at least 1 according to Figure 5-1 of the device datasheet. You can view example msp430f66xx_UCS_03.c for a demonstration of how to do this. Furthermore, please try to run example msp430f66xx_UCS_07.c with the following changes:

    1. XT2DRIVE set to 1h inside of UCSCTL6 since you are using a 12 MHz external oscillator.
    2. Do not set the internal load cap bits (XCAP) inside of UCSCTL6 because you use external load caps.
    3. Turn off XT2 and enter LPM3 during the while loop, probing P1.0 with an oscilloscope to see if ACLK stops.

    If the issue persists then the problem most likely has to do with your crystal hardware, if not then the clock initialization is probably at fault.

    Regards,
    Ryan

    My MCLK Frequency is 5 Mhz, checked the Output at MCLK PIN and obtained the same. 

    1. I tried with MAX drive strength for both XT1 and XT2 , and XT2 is 16Mhz.

    2. Tried Removing the External Caps on XT1 .

    3. I am probing directly at the XT1 Crystal and it stops immediately after entering the LPM3.

    The evaluation Board with same controller was working, so we tried swapping the Caps and XT1 from the eval board but didnt resolve.

  • The issue is solved.

    In my design, the VBAT Pin was left unconnected. As per the user's manual it should be connected to DVcc when not used.
    Connecting the VBAT to DVcc solved the problem.

    On EVAL board VBAT and DVCC were shorted using a jumper. tried removing the jumper and the same issue was observed on the EVAL board too.

    1. I have no clue why the XT1 was relying on VBAT supply when the DVCC was not turned off.
    2. Why XT1 was working fine if XT2 was not turned OFF ?

    Anyways, the issue is solved :)

**Attention** This is a public forum