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.

code for enabling external crystal

Other Parts Discussed in Thread: MSP430F5419A, ENERGIA

Hello-

We are using the msp430f5419a and would like to run our RTC off the external crystal. Do you have any example code you could share?

Here’s the clock test code we made.  We now know that it is not using the crystal as we grabbed an MSP-TS430PZ5x100 and that doesn’t have a crystal by default and the code below still works!  So we’re a little bit stumped as we think we’re telling it to use the external crystal.

Built with Energia, an MSP430 variant of Arduino.  We modeled the code after msp430x54x_ta3_05.c from the slac166s download from TI for examples.

volatile unsigned int counter = 0;

volatile int tick = LOW;

unsigned long startTime;

float percentOff;

boolean pin = LOW;

 

void setup()

{

  //Serial.begin(9600);

  pinMode(MPU_LED, OUTPUT);

  digitalWrite(MPU_LED, pin);

  pinMode(DEBUG_UARTRXD, OUTPUT);

  digitalWrite(DEBUG_UARTRXD, LOW);

  pinMode(17, OUTPUT);

  digitalWrite(17, LOW);

 

  delay(1000);

  //Serial.println("Started");

 

  //Serial.println(UCSCTL4);

  //Serial.println(UCSCTL4, HEX);

  //Serial.println(UCSCTL4, BIN);

 

  //        SELA(XT1CLK) | resv  | SELS(DCOCLK) | resv  | SELM(DCOCLK)

  UCSCTL4 =       0 << 8 | 0 < 7 | 3 < 4        | 0 < 3 | 3; //We want 51 = 00000110011; //We saw 1000110011

  //        XT1DRIVE | XTS    | XT1BYPASS | XCAP   | SMCLKOFF | XT1OFF

  UCSCTL6 = 0 << 6   | 0 << 5 | 0 << 4    | 3 << 2 | 0 << 1   | 0; //We want 000000011100000

 

  //Serial.println(UCSCTL4);

  //Serial.println(UCSCTL4, HEX);

  //Serial.println(UCSCTL4, BIN);

 

  counter = 0;

  startTime = millis();

  ConfigTimerB(); //Configure the timer

}

 

void loop()

}

 

/*****************************************************************

*

* FUNCTION: configTimerA

*

* PURPOSE: Configure the TimerA

*

* PARAMETERS: delayCycles: number of clock cycles to delay

*

*****************************************************************/

 

void ConfigTimerB()

{

    TB0CCTL0 = CCIE;                          // TACCR0 interrupt enabled

    TB0CCR0 = 1000 - 1;

    TB0CTL = TBSSEL_1 + MC_1 + TBCLR;

}

 

/*****************************************************************

*

* FUNCTION: Timer_A0

*

* PURPOSE: Interrupt Handler to service the TimerA0 interrupt

*

* PARAMETERS: none

*

*****************************************************************/

 

#pragma vector=TIMER0_B0_VECTOR

__interrupt void Timer_B0(void)

{

   digitalWrite(17, !digitalRead(17));

}

Thanks and Best Regards,

Tim Starr on behalf of DA@MI

  • Hi Tim,

    If you have no crystal populated but have XT1 selected for ACLK, the fault logic will cause ACLK to fall back to being sourced from REFO - REFO is also 32kHz, but it is not as accurate as an external crystal. See the 5xx user's guide www.ti.com/lit/pdf/slau208 section 5.2.12 UCS Module Fail-Safe Operation:

    "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). This does not change the SELA bit settings. This condition must be handled by user software"

    So, if this happened I could see that your code might still seem to work ok even though you didn't have the crystal there, since it falls back to another ~32kHz clock.

    If you want to make sure the crystal is really getting used, you should have a loop that checks the fault flag for it to clear after you enable the crystal. Please see our UCS code examples for this device, or use the driverlib function for enabling the crystal (which will do this fault checking for you).

    I'd also recommend using the driverlib APIs for initializing your crystal and other clocks - then the fault flag checking will be handled for you and it will be easier to read than the bit shifts you have in there at the moment.

    Regards,

    Katie 

  • Were those single "<" in

    UCSCTL4 =       0 << 8 | 0 < 7 | 3 < 4        | 0 < 3 | 3; //We want 51 = 00000110011; //We saw 1000110011

    also intended to be bit-shifts?

  • They likely were.
    I wonder why the result is 0x0233 - I would expect 0xFFFF, because (0<7) is true and therefore -1

**Attention** This is a public forum