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.

MSP430FR5739 UART example code does not work



I have loaded the example code from the slac491.zip and tried to use the uart_03 example.  I am using the 5739 exp board that contains the accel, ntc, and emulation section with the UART back port.  the FRAM_GUI recognizes the board when plugged in but the dash board does not indicated any data.  I then attempted to attach a tera term at 9600 baud and got nothing as well as no break point occurring at the interrupt handler switch case.  So is the back port not accessible?  Or do I have to do something special to use it?  If then how does the FRAM GUI use it?  Here is the code:

#include <msp430.h>

unsigned int i;
unsigned char RXData = 0;
unsigned char TXData = 0;
unsigned char check = 0;
int main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // stop watchdog

  // XT1 Setup

  PJSEL0 |= BIT4 + BIT5;

  CSCTL0_H = 0xA5;
  CSCTL1 |= DCOFSEL0 + DCOFSEL1;             // Set max. DCO setting
  CSCTL2 = SELA_0 + SELS_3 + SELM_3;        // set ACLK = XT1; MCLK = DCO
  CSCTL3 = DIVA_0 + DIVS_3 + DIVM_3;        // set all dividers
  CSCTL4 |= XT1DRIVE_0;
  CSCTL4 &= ~XT1OFF;

  do
  {
    CSCTL5 &= ~XT1OFFG;
                                            // Clear XT1 fault flag
    SFRIFG1 &= ~OFIFG;
  }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag

  // Configure UART pins
  P2SEL1 |= BIT0 + BIT1;
  P2SEL0 &= ~(BIT0 + BIT1);
  // Configure UART 0
  UCA0CTL1 |= UCSWRST;
  UCA0CTL1 = UCSSEL_1;                      // Set ACLK = 32768 as UCBRCLK
  UCA0BR0 = 3;                              // 9600 baud
  UCA0BR1 = 0;
  UCA0MCTLW |= 0x5300;                      // 32768/9600 - INT(32768/9600)=0.41
                                            // UCBRSx value = 0x53 (See UG)
  UCA0CTL1 &= ~UCSWRST;                     // release from reset
  UCA0IE |= UCRXIE;                         // Enable RX interrupt

//   __bis_SR_register(LPM0_bits + GIE);      // LPM3 + Enable interrupt
  _enable_interrupts();
  while(1) {}
}


// Echo back RXed character, confirm TX buffer is ready first
#pragma vector=USCI_A0_VECTOR
__interrupt void USCI_A0_ISR(void)
{
  switch(__even_in_range(UCA0IV,0x08))
  {
  case 0:break;                             // Vector 0 - no interrupt
  case 2:                                   // Vector 2 - RXIFG
    while (!(UCA0IFG&UCTXIFG));             // USCI_A0 TX buffer ready?
    UCA0TXBUF = UCA0RXBUF;                  // TX -> RXed character
    break;
  case 4:break;                             // Vector 4 - TXIFG
  default: break;
  }
}

  • As I can see UCS must be 92h, write UCA0MCTLW = 0x9200 and don’t use OR (|) while other should be zero.

    Using low frequency crystal at this baud rate gives high percentage of error. Using DCO would give much better result.

  • I removed the OR.  It is spotty but a least I am now getting the break point at the interrupt.  Nice catch.  Note: This example code was taken directly from the latest download example code without modification.

    Thanks

  • Greg Greenwood1 said:
      CSCTL2 = SELA_0 + SELS_3 + SELM_3;        // set ACLK = XT1; MCLK = DCO

    Do you have the crystal attached to XT1? The code requires it, but on some  boards, the crystal is not soldered by default (to allow alternative usage of the MSP pins if the MSP has no dedicated XT1 pins).

  • Yes.  The crystal is in place and working.  In fact the code would not have cleared the oscillator fault had it not been there.  I find the communication spotty even if I use the DCO at a higher frequency to reduce the error at 9600.  It is interesting that only certain characters make it through 100%.  The characters that do not make it through, never make it through.  Is the F1611 filtering what is passed on to the FR5739?

  • It looks like you have an alignment error and one or more bits are missing (or too much). You can try to alter the BRW by +/- 1 or more counts and look what you are receiving. In my software I have a note not to use the UCxIV switch (can’t trust it) but can’t remember why, but I’m using it on a more complex way and have interrupts on more events and manual compare the interrupt/status flags.

    Put a break point at the first line in your ISR and look which flags are set in Status and IFG and also which character you have received.

    Additional you can try the internal loopback mode to check if the module is working properly.

  • Greg Greenwood1 said:
    The crystal is in place and working.  In fact the code would not have cleared the oscillator fault had it not been there. 

    You're right. However, it may be that the crystal fails later. I see that you are using driving strength 0.

    Greg Greenwood1 said:
    Is the F1611 filtering what is passed on to the FR5739?

    No. There is a direct connection between the TUSB and the target, even though the 1612 is attached to it too (IIRC).

    Greg Greenwood1 said:
    It is interesting that only certain characters make it through 100%.  The characters that do not make it through, never make it through.

    Well possible. Depending on the bit pattern, a wrong baudrate can cause framing errors on certain characters while not causing one on others. For example: If the last bit sent before the stop bit is '0', this can cause a framing error (stop bit is seen as '0' too).

  • Fixed it.  Works great.

    Used the SMCLK at 6MHz (MCLK = 24MHz, prescaled by 4) then:

      UCA0BR0 = 0x68;
      UCA0BR1 = 0x02;
      UCA0MCTLW_L = 0x00;
      UCA0MCTLW_H = 0x00;

    .

  • Sorry.  Meant to add the Baud rate is now 115.2K

    Thanks

  • Greg Greenwood1 said:
      UCA0BR0 = 0x68;

    Should be 0x71: 6,000,000/9600 = 625 = 0x271

    BTW: the built-in application UART is limited to 9600Bd. For 115,200Bd you'll need a separate USB/SER converter and level shifter.

  • Sorry if I was not clear.  The current settings:

          UCA0BR0 = 0x68;
          UCA0BR1 = 0x02;
          UCA0MCTLW_L = 0x00;
          UCA0MCTLW_H = 0x00;

    work in a system where the MCLK = 24MHz, the SMCLK = 6MHz, and the Uart baud = 115.2K through the USB COMM bridge.

    I arrived at the UCA0BRx values by hooking scope to the Rx and Tx lines (P2.0, P2.1) and matching the bit cell timing.

    It does not agree with the math presented in your last post.  Not sure why.  I will delve into it later as I am on a tight schedule to get the proto up.

  • Greg Greenwood1 said:
    arrived at the UCA0BRx values by hooking scope to the Rx and Tx lines (P2.0, P2.1) and matching the bit cell timing.

    Well, the scope might be off. After all it is only 1.5% error. :)

    Also, the other peer might have a clock error too. Or your crystal is bad. Well, 1.5% error is huge for a crystal. I doubt that just a wrong load capacitance can make so much detuning.

    Greg Greenwood1 said:
    I will delve into it later as I am on a tight schedule to get the proto up.

    good luck!

**Attention** This is a public forum