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.

How do I access the XT2 RF clock for the UCA0?

Other Parts Discussed in Thread: CC430F6137

Having trouble using the 26MHz crystal (XT2) to drive the UART clock on a cc430F6137. My code below shouldn't work but it does... 90% of the time. It is supposed to work from XT2 with a DIV_2, BR0=32 and BR1=3. There's some background below if needed. Thanks!!$%^@$!@#!#

void main(void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop WDT

PMAPPWD = 0x02D52; // Get write-access to port mapping regs
P2MAP6 = PM_UCA0RXD; // Map UCA0RXD output to P2.6
P2MAP7 = PM_UCA0TXD; // Map UCA0TXD output to P2.7
PMAPPWD = 0; // Lock port mapping registers

P2DIR |= BIT7; // Set P2.7 as TX output
P2SEL |= BIT6 + BIT7; // Select P2.6 & P2.7 to UART function

UCSCTL4 |= SELS__XT2CLK; // SMCLK=XT2

UCSCTL6 &= ~XT2OFF; // Enable XT2 (26MHz) 

UCA0CTL1 |= UCSWRST; // **Put state machine in reset**
UCA0CTL1 |= UCSSEL_2; // SMCLK (Hmmm, maybe should be before the reset?)

UCSCTL5 |= DIVS_2; // /2

UCA0BR0 = 0x08; // Why does this work with MIDI at all???

UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine**

UCA0IE |= UCRXIE; // Enable USCI_A0 RX interrupt

while (1) // just sending MIDI commands to play a note
{

while (!(UCA0IFG&UCTXIFG)); // USCI_A0 TX buffer ready?

UCA0TXBUF = 0x91; //

while (!(UCA0IFG&UCTXIFG)); // USCI_A0 TX buffer ready?
UCA0TXBUF = 0x3C; // send 1010 1010 data
while (!(UCA0IFG&UCTXIFG)); // USCI_A0 TX buffer ready?
UCA0TXBUF = 0x7F; // send 1010 1010 data
P1OUT ^= BIT0; // Toggle LED1
__delay_cycles(5000); // pause between transmissions
}
}

Background:

My "clock" crystal is not quite accurate enough for MIDI specs (31.25K +/- 1%) so the DCO/FLL is not an option over the operating range. This MIDI frequency is a common problem in the music industry trying to get 31,250 Hz off a 32,786 crystal (used for time). The above code is picking it up about 90% of the time. I suspect I'm using a different clock like the CPU (which may be changing speeds based on shifting power modes), or just getting lucky because it's close - but no cigar (not good enough). 

  • Consider this. I measured on a scope running the above code and it's at 33,333 Hz (which is ~7% too fast for MIDI). This measurement is quite accurate because I used the same equipment to look at a known MIDI signal.

    But how is that possible with a DIV_2 and BR0 = 8? That's a 1/16th clock which means the source clock is at 533,328. So what is my actual source clock?  Or a better question is how do I source the 26MHz so it's easy to get 31,250? I'm soooo close!

    Thanks!

  • Maybe you need to swap these two lines of code?

    UCSCTL4 |= SELS__XT2CLK; // SMCLK=XT2

    UCSCTL6 &= ~XT2OFF; // Enable XT2 (26MHz) 

    According to the cc430 user guide selecting XT2 is not always guaranteed: "101b = XT2CLK when available, otherwise DCOCLKDIV". Here is the fault bit operation:

    "The crystal oscillator fault bits XT1LFOFFG, XT1HFOFFG, and XT2OFFG are set if the corresponding crystal oscillator is turned on and not operating properly. Once set, the fault bits remain set until reset in software, regardless if the fault condition no longer exists. If the user clears the fault bits and the fault condition still exists, the fault bits are automatically set, otherwise they remain cleared."

    and one other note: "When the RF oscillator is disabled the corresponding fault flag XT2OFFG is set and if the RF oscillator is selected to source ACLK, MCLK, SMCLK or FLLREFCLK the corresponding fail-safe mechanism takes over."

    So I would say since you select the XT2 before forcing it on, the fault bit is getting set and you are using the DCO instead.

  • John DAmours said:
    UCSCTL5 |= DIVS_2; // /2

    No, DIVS_2 is not /2 but rather /4. (DIVS_0 is /1, DIVS_1 is /2). You probably meant DIVS__2 (note the double-underscore) which indicates a value rathehr than an enumerated option (one underscore) or a bit (no underscore).

    John DAmours said:
    UCA0CTL1 |= UCSWRST; // **Put state machine in reset**
    UCA0CTL1 |= UCSSEL_2; // SMCLK (Hmmm, maybe should be before the reset?)

    No, during reset is right. SWRST pulls and holds the state machine in start position. Configurations changes may only be applied while SWRST is set. Else the change may or may not or perhaps only partly used during operation.

    John DAmours said:
    UCSCTL6 &= ~XT2OFF; // Enable XT2 (26MHz) 

    After enabling the XT2, you'll have to wait for it to comeonline. This may take some ms. Use the fault bits to check whether it is stable. The procedure is described in the users guide.

    John DAmours said:
    UCA0BR0 = 0x08; // Why does this work with MIDI at all???

    It doesn't. But sometimes, an unltrahigh baudrate can be triggered by a lmuch lower baudrate and fetch 'something' from the input. Especially if you don#t chekc for framing errors.
    The required divider for 13MHz SMCLK would be 416 (UCBR1=1 and UCBR0=160)

    John DAmours said:
    UCSCTL4 |= SELS__XT2CLK; // SMCLK=XT2

    This only works by coincidence. The initial value of SELS is SELS__DCOCLKDIV, which is 100. if you OR SELS_XT2CLK, which is 101, then the result is 101 and the intended one. However, trying to set it to DCOCLK instead, which is 011, would result in 111.
    You cannot simply OR bitfields (options with mroe than one bit) into an existing value. You have to ensure first that all bits are clear or you are just combining settings and get a completely different result.

  • I tried adding delays to give time for the clock to settle, but that didn't change things.

    However, agreeing it's still an error with XT2 availability, I decided to integrate with my other code that uses the radio. BINGO - exactly 31,250!  Our app uses the radio with MIDI, so not a problem or a waste of energy.  

    So I think you're both correct regarding faults on XT2 readiness and tenuous availability as stated in the TI docs. 

    Way to go - that's teamwork!

    21

**Attention** This is a public forum