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

Other Parts Discussed in Thread: MSP430FR5739, ENERGIA, MSP-EXP430FR5739

Hi, I am using CCS, with the MSP430FR5739 Exp board. I did a few examples a while ago, including using the printf function to complete the 'hello world' tutorial. I tried using the example code (seen in thread http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/301422.aspx), found in the MSP430FR57XX code examples folder. From this I learnt that XT1 would constantly generate a fault flag, which prevents any of the examples being used as given.

I modified the example so as to remove the XT1, and replaced it with the DCO. From the UG, this gives a DCO frequency of 8 MHz, which is divided by 8 for the SMCLK, which I specify as the baud rate clock. I calculated manually and from the UG for BRCLK = 1 MHz; BAUD = 9600; Oversampling ON, BRx = 6, RFx = 8 and RSx = 0x20.

Nothing appears on my putty terminal. I enabled loopback mode and this sends/receives the same character. I have adjusting the BR, RF and RS to give various baud rates - I don't even get junk in putty. 

Appreciate any help! ( I have tried putting back on previous code which performed the hello world and that doesn't work anymore, also tried energia - but opening the serial monitor causes energia to crash, but nothing through putty)

#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

CSCTL0_H = 0xA5; // Unlock CS register

CSCTL1 |= 0x0006; //  SET DCO to 8 MHz (DCOFSEL to 11b)

CSCTL2 = SELA_3 + SELS_3 + SELM_3; // set ACLK = DCO; SMCLK=DC0; MCLK = DCO; 

CSCTL3 = DIVA_0 + DIVS__8 + DIVM_0; // set all dividers
CSCTL0_H = 0x01; // Lock Register

// Configure UART pins

P2SEL1 |= BIT0 + BIT1;

P2SEL0 &= ~(BIT0 + BIT1);


// Configure UART 0
UCA0CTL1 |= UCSWRST; // Unlock UART registers


UCA0CTLW0 |= 0x00C0; // Set UCSSELx to 11b  (SMCLK)


UCA0BRW = 6;
UCA0MCTLW |= 0x2081; // RSx = 0x20h | RFx = 1000b | XXX | UC0S16 = 1

//UCA0STATW |= UCLISTEN; // Uncomment to enable loopback mode. 

UCA0CTL1 &= ~UCSWRST; // release from reset
UCA0IE |= UCRXIE; // Enable RX interrupt

_enable_interrupts();

while(1){

if ((UCTXIFG)){  // If TXBUF is empty then send a new character
UCA0TXBUF = 't';
}


}


// Echo back RXed character, confirm TX buffer is ready first
#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector=USCI_A0_VECTOR
__interrupt void USCI_A0_ISR(void)
#elif defined(__GNUC__)
void __attribute__ ((interrupt(USCI_A0_VECTOR))) USCI_A0_ISR (void)
#else
#error Compiler not supported!
#endif
{
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
PJOUT |= PJOUT + 1;
break;
case 4:break; // Vector 4 - TXIFG
default: break;
}
}

  • As an update to this I've now used a different microcontroller (LM4F120) and energia, and taken the headers off the MSP430 TX and RX, and tried to test the RS232 link on the MSP430 - and get nothing. This made me think that it was just the converter which is busted... but attaching a wire from the RX to TX on the MSP430, as a hardware loopback test, I get no response, nor from connecting the TX of LM4F to RX of MSP430. 

  • Still haven't gotten any further with this. Do I buy another MSP430FR assuming BOTH RS232 and UART module (internal) have busted. Seems unlikely to have both fail? 

  • Peter Morris1 said:
    RS232 and UART module (internal)

    With what and how do you connect your MSP-EXP430FR5739 board?

    The MSP-EXP430FR5739 board nor the MSP430FR5739 MCU doesn’t have a RS232 or UART module.

  • Sorry I meant the ''eUSCI_A – UART Mode", was just being lazy in typing. 

    I connect using a cable that I think is a mini-A to USB, I've used the same cable for an external hard drive. I definitely managed a hello world using printf, this uses a converter like RS232? 

  • What when the members here are also Lazy and just throws some words to you, would that helps you?

    If you don’t know the meaning of these then don’t be lazy and starts to search Goole for it and learn! The members here will not do this for you.

    ‘printf’ and ‘RS232’ has nothing to do with each other.

    ‘printf’ is just a piece of software which helps you to format a string for displaying, you can merge values into the string or align the text and much more. To write just the string “Hello world” to a terminal screen you don’t need ‘printf’.

    ‘RS232’ is an older (but still commonly used) hardware protocol and specifies the hardware connections and voltage levels, + and – ~10V. The voltage levels of Tx and Rx on your EVM are 0V and ~3.3V, so connecting them together will be catastrophic four your EVM hardware.

    ‘USB’ is the more modern way of connecting electronic devices, but needs special hardware which is not available in most MSP430 devices. Therefore TI provides you with an USB driver which creates a virtual COM-port on your PC and hardware on your EVM to translate the Tx and Rx pins of your MCU and transceive them trough your USB connection.

    Well, using the USB cable and setting the jumpers according the EVM manual, nothing dangerous can happens to your hardware.

    Now to cleanup your chaos, setup the board to the defaults described in the EVM manual and start with the blinking LED example to see if your EVM and USB connection is are still working. Then you can expand and go to the USCI loopback/echo example and check your USCI.

  • Sorry for the offence I caused, I'm not accustomed to using these forums/asking for help! I worked somewhere where RS232 and USB were used synonymously which is unfortunate. I am familiar with the concept that RS232 defines the hardware and the charge pump within converters can be catastrophic for devices - I've destroyed communications to an arduino before with this. I did not connect the Tx and Rx output of the RS232 converter together. 

    Thank you for clearing up the definitions though, is appreciated.

    I restored jumpers to original positions, loaded an example which blinks an LED and this worked okay - I had to modify where it said P1 to PJ to direct the output to the on board LEDs. 

    I then put in printf("hello world") (which I no longer understand how it works, I thought this made use of the RS232 hardware to transmit from MSP430 to computer - though you imply this is not the case?), this statement is only sent to the console as I understand it. 

    I then created a new project into which I copy and pasted the ''MSP430FR57xx_uscia0_uart_03'' example. This uploads and I open a putty terminal at 9600 baud on the correct com port. This example is a USCI echo. I do not receive an echo. Debugging I find that the program haults at line:

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

    It indicates there is a fault with XT1. From what I have read in the User Guide, this is connected to the crystal which is on the Evaluation Board. I did not fit the crystal as I was loaned this board from department. I figure the best option is to use one of the other clock sources as the feed for the baud rate clock (UG: BRCLK). Still using the example mentioned, I change the clock source for ACLK from XT1 to DCOCLK. DCOCLK has a default value of 8MHz, and is initialised in the example to 8MHz. I set the divider for ACLK to be 8. This should set ACLK to 1MHz. In Table 18-5 of the UG.

    Reprogramming the example program now hangs at this line: 

    __bis_SR_register(LPM0_bits + GIE);      // LPM3 + Enable interrupt

    This bit of code should put the micro into low power mode, and turns off MCLK (http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/265652.aspx)

     GIE I'm going to guess is general interrupt enable or some such. I notice there is a function __enable_interrupts() so I swap the hanging function for this. The code at this stage looks like this (excluding interrupt routine):

    #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

    CSCTL0_H = 0xA5;

    CSCTL1 |= DCOFSEL0 + DCOFSEL1; // Set max. DCO setting - 8 MHz DCORSEL == 0
    CSCTL2 = SELA_3 + SELS_3 + SELM_3; // set ACLK = DCO; MCLK = DCO; SMCLK = DCO
    CSCTL3 = DIVA__8 + DIVS_3 + DIVM_3; // set all dividers
    //CSCTL4 |= XT1DRIVE_0; // Set drive strength of XT1 to lowest
    CSCTL4 |= XT1OFF;

    // Configure UART pins

    P2SEL1 |= BIT0 + BIT1;
    P2SEL0 &= ~(BIT0 + BIT1);
    // Configure UART 0
    UCA0CTL1 |= UCSWRST;
    UCA0CTL1 = UCSSEL_1; // Set ACLK = 32768 as UCBRCLK EDIT: ACLK = 250000
    UCA0BR0 = 6; // 9600 baud
    UCA0BR1 = 0;
    // Baud, UCOS16, BR, BRF, BRS
    // 9600 1 6 8 0x20 - From Table 18-5 of User Guide
    // UCA0MCTLW = 15-8: BRS, 7-4: BRF, 3-1: RES, 0: UCOS16
    UCA0MCTLW |= 0x2081; //
    UCA0CTL1 &= ~UCSWRST; // release from reset
    UCA0IE |= UCRXIE; // Enable RX interrupt
    _enable_interrupts();
    // __bis_SR_register(LPM0_bits + GIE); // LPM3 + Enable interrupt
    PJDIR |= 0x01;
    PJOUT == 0x01; // Turn LED On to indicate finishing.

    }

    No UART echo. I question whether the ''Configure UART pins'' block actually enables the UART pins? I have read that this example has worked as-is for other people so I question also whether __bis_SR_register plays a crucial role in this code. I pause the programme in CCS after typing a few characters into putty (which I close and reopen with each reprogramming)  no response. I open register view and see that 'UCA0RXBUF' reads 0x0000 indicating nothing is in the receive buffer. There is also no error set in  UCA0STATW.

    I add in to the eUSCI_A0 initialisation routine UCA0STATW |= UCLISTEN which enables loop back mode. I also add 'UCA0TXBUF = 't';' before the LED lights. I reprogramme. I click play. LED lights and code halts the breakpoint. The UCA0RXBUF now reads 0x0074. The code is now trapped within this interrupt routine as it transfers the Rx buffer to Tx.

    Sorry for the lengthy post. I am now at the point where I have no ideas where to take this. I am not convinced that the pins for the UART or eUSCI_A0 module have actually been set up correctly. The only tool I have at my disposal to check the output is an LM4F120. I have tried connecting UART1 of the LM4F to the pins of the MSP430 (through jumper wires to the breakout headers). It detects nothing. 

    I really would appreciate any help on this, even if it is to correct my technical language! I've tried to be clear and methodical here in case I am causing the problem. I have repeated this entire process (new project, blinky -> example usci). 

  • Peter Morris1 said:
    (which I no longer understand how it works, I thought this made use of the RS232 hardware to transmit from MSP430 to computer

    On your computer (PC) you can have a RS232 connector and a USB connector. Most computers today has only a USB connector. The EVM has only a USB connector. So you can forget the RS232 totally.

    Default the EVM has not installed the crystal and unfortunately there is no example which use the build-in DCO clock, which is less precise but usable. You either install the crystal or convert the example to use the DCO (which you did).

    If not using the LPM (which is a good idée for now) and enable only the interrupts (GIE, and lave it enabled) you need to add at the end of main a loop otherwise main will exit here and everything stops, add while(1);.

    I didn’t check carefully the remaining of your code (at the moment time is a little bit limited) but add the while and check again, you are on the good way.

  • I've always treated USB as a software only side of things, and never really looked in to the hardware - if I can send/receive computer to device thats fine for me at this stage.

    There is a crystal on the board, but have no details as to what this is or what capacitors are fitted. I am pretty much discounting that its working, and I seem to have made the DCO clock work for the peripheral, seeing as the USCI works in loopback mode! 

    I realised how setting the LPM works through the UG a bit better and tested with loopback enabled and quite happy with how this works. Nevertheless I tried with enable only interrupts and a while(1) loop. No surprise no change! 

    Am I correct in assuming that by setting the PxSEL0 and PxSEL1 registers (to select which functionality on the IO is enabled) I do not need to take additional steps such as PxDIR etc? 

  • Peter Morris1 said:
    Am I correct in assuming that by setting the PxSEL0 and PxSEL1 registers (to select which functionality on the IO is enabled) I do not need to take additional steps such as PxDIR etc? 

    I understand you’re not a hardware guy! But to make good software for these MCU’s some knowledge of the hardware will be welcome. Have a look into the data sheet under Input/Output Schematics there you will find your answer, if not ask again.

  • Actually I am more of a hardware guy! Just never had experience beyond RS232 for serial communications! (degree just finished - hence not very experienced just yet!) I looked through the datasheet and know that USCI UART mode is on Port 2, pins 0 and 1, and it is the secondary function. Therefore, assuming the UG is correct, the UART mode has been configured for these pins correctly. There is nothing in the section about initialisation of the USCI to UART mode to any steps with regards to the pins. I have looked through every UART example I can find and none take any extra steps. It seems that my problem should not be occurring - hence I'm questioning even if the resources TI have provided are actually correct.

    Therefore I tried every combination on the PxSEL0 and PxSEL1 registers just in case, but did not work. Im considering a few 'next steps':

    use the same code for USCI1 - see if I get the same problem. 

    try to see if Pin 1, Pin 2, Port 2 are bust (use as digital IO on LED).

    abandoning this EVM for a new one.

  • The Data Sheet describes only the internal hardware connections, pin to GPIO or Module (USCI or whatever) and is specific for this device only, the descriptions about how the Modules are working (UART etc) is in the Users Guide and is common for a lot of devices.

    The SEL register defines how the pin is connected, normal as GPIO or to a Model function. When GPIO the DIR controls the direction, when Module the Module controls the direction. The REN can be active in both cases.

    If you enable UCLISTEN of the USCI and disconnect the IO pins by SEL=0 the internal loopback must work even when the port pins are busted.

    The port pins themselves you can check by enabling them as GPIO (SEL=0, DIR=1), remove the RxD and TxD jumpers and alter the OUT by software and measure the voltage at the pins.

    I can’t check your program while I managed to blow-up my USB chip on the EVM, and can only use the JTAG connection for programming.

  • I have had problems with datasheets in the past (mainly op-amps) so I've learnt not to 100% trust what they say. 

    I did as you suggested, except I don't have a multimeter at the moment - just wired the pins up to res + LED. The LED turned on for both Rx and Tx (or 2.0 and 2.1 ). I was hoping this wouldn't work then at least I could blame this problem on a busted board! It seems that UART does not connect to 2.0 and 2.1 the way I have set it up, but i have altered the SEL register for every combination already! 

    Hopefully someone else might be able to stick the code on to give it a try! 

  • Peter Morris1 said:
    I have had problems with datasheets in the past (mainly op-amps) so I've learnt not to 100% trust what they say.

    Sometimes you need to implement them on a creative way.

    Did you try the internal loopback/echo, this is the easiest way to check the USCI? Then post your code with this setup, use the code insert button this makes it more readable.

  • I did try with internal loopback/echo. It works fine, and just requires one bit to be set in UCA0STATW. Interrupts the code as expected. The full code as it currently stands is below. (hopefully insert code worked!)


    #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 // Clock Setup CSCTL0_H = 0xA5; CSCTL1 |= DCOFSEL0 + DCOFSEL1; // Set max. DCO setting - 8 MHz DCORSEL == 0 CSCTL2 = SELA_3 + SELS_3 + SELM_3; // set ACLK = DCO; MCLK = DCO; SMCLK = DCO CSCTL3 = DIVA__8 + DIVS_3 + DIVM_3; // set all dividers //CSCTL4 |= XT1DRIVE_0; // Set drive strength of XT1 to lowest CSCTL4 |= XT1OFF; // Configure UART pins P2SEL1 |= BIT0 + BIT1; P2SEL1 &= ~(BIT0 + BIT1); // Configure UART 0 UCA0CTL1 |= UCSWRST; UCA0CTL1 |= UCSSEL_1; // Set ACLK = 32768 as UCBRCLK EDIT: ACLK = 250000 UCA0BR0 = 6; // 9600 baud UCA0BR1 = 0; //UCA0STATW |= UCLISTEN; // Enable loopback mode // Baud, UCOS16, BR, BRF, BRS // 9600 1 6 8 0x20 - From Table 18-5 of User Guide // UCA0MCTLW = 15-8: BRS, 7-4: BRF, 3-1: RES, 0: UCOS16 UCA0MCTLW |= 0x2081; // UCA0CTL1 &= ~UCSWRST; // release from reset UCA0IE |= UCRXIE; // Enable RX interrupt _enable_interrupts(); // _bis_SR_register(LPM0_bits + GIE); // LPM3 + Enable interrupt // UCA0TXBUF = 't'; // Enable this if in loopback mode PJOUT |= 0x01; while(1){ // while loop needed if not in LPM } } // Echo back RXed character, confirm TX buffer is ready first #if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__) #pragma vector=USCI_A0_VECTOR __interrupt void USCI_A0_ISR(void) #elif defined(__GNUC__) void __attribute__ ((interrupt(USCI_A0_VECTOR))) USCI_A0_ISR (void) #else #error Compiler not supported! #endif { 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; } }

  • Can you confirm that the internal loopback/echo works as expected? In that case you didn’t need to post the code (I should mend that) while this is ok than.

  • Leo Bosch said:

    Can you confirm that the internal loopback/echo works as expected? In that case you didn’t need to post the code (I should mend that) while this is ok than.

    I am hoping someone might put it on their board and tell me if it works or not :p. Yes, enabling loopback mode I transmit one character (putting 't' into the Tx Buffer), and the program immediately jumps into the interrupt routine - signalling the reception of a character. I had a breakpoint within this routine, and at this point I looked at the registers and see that 't' is now present in the Rx Buffer. 

  • When USCI, IO port and USB works, there not much left to check. The last things could be the USCI port pins from the USB chip and your PC com port. If you are using CCS you can open a Terminal window (View/Other), connect by serial and select the com port.

    Later the day I can maybe try it on the FR5969 EVM, but it’s not the same.

  • I clicked connect, said connected. Tried to enter text into the terminal, CCS crashed. It just seems as though something is preventing the pins from being used by the USCI. I think the exercise of using the DCO as clock source should be near identical, and may see whether thats an issue, not that it should be! 

    The only other theory I have left seems illogical, that somehow the XT1 clock is still connected/controlling the pins in some way and blocking their use. That or something else has a hold. I haven't seen anything about this at all though and dont really believe this, but as you say - get creative! 

  • It looks you have some problem on your PC, CCS should not crash even when wrong com settings you get garbage or nothing but not a crash.

    The Xtal pins have nothing to do with the Tx or Rx pins on the EVM, but even when, CCS should not crash.

    Check/update Windows, maybe something wrong with the TI USB driver.

    In the Terminal window you see only one com port?

  • So a bit of playing around with this, it doesn't crash, CCS hangs. If I unplug the device I get an 'IO ERROR' (in writeByte).

    I did some playing around with the TI driver before because I noted windows had given it a generic device driver ( I don't recall the specifics), and switched it to the TI one.

    In the terminal window I can only see one COM port

  • Peter Morris1 said:
    CCS hangs. If I unplug the device I get an 'IO ERROR' (in writeByte).

    Then this is your problem, at least for now.

    When I plug in the FR5969 EVM I get under Device Manager\Ports (COM & LPT); MSP Application UART1 (COM20) & MSP Debug Interface (COM19). You should at least see the MSP Application UART with the same COM port as in the terminal settings.

  • I have MSP430 Application UART (COM4). This is the same as I'm using in the terminal.

  • G2 LaunchPad gives same text as you have, so must be correct.

    What version of CCS are you using (5 or 6)?

  •  Version: 5.5.0.0007

  • I quickly load it into FR5969 a few changes, in the begin I got some (wrong) echoed characters but now nothing, and no hanging or crashing CCS. Will try later.

    Bad or too long USB cable or using a HUB can also causes communication problems.

  • This example is working on my EVM, compare it with your software maybe you can find some difference. There is a minor difference between both FRAM’s at least at enabling port registers.

    #include "msp430.h"
    
    int main(void)
    {
      WDTCTL = WDTPW | WDTHOLD;                 // Stop Watchdog
    
      // Configure GPIO
      P2SEL1 |= BIT0 | BIT1;                    // USCI_A0 UART operation
      P2SEL0 &= ~(BIT0 | BIT1);
    
      // Disable the GPIO power-on default high-impedance mode to activate
      // previously configured port settings
      PM5CTL0 &= ~LOCKLPM5;
    
      // Startup clock system with max DCO setting ~8MHz
      CSCTL0_H = CSKEY >> 8;                    // Unlock clock registers
      CSCTL1 = DCOFSEL_3 | DCORSEL;             // Set DCO to 8MHz
      CSCTL2 = SELA__VLOCLK | SELS__DCOCLK | SELM__DCOCLK;
      CSCTL3 = DIVA__1 | DIVS__1 | DIVM__1;     // Set all dividers
      CSCTL0_H = 0;                             // Lock CS registers
    
      // Configure USCI_A0 for UART mode
      UCA0CTLW0 = UCSWRST;                      // Put eUSCI in reset
      UCA0CTLW0 |= UCSSEL__SMCLK;               // CLK = SMCLK
      // Baud Rate calculation
      // 8000000/(16*9600) = 52.083
      // Fractional portion = 0.083
      // User's Guide Table 21-4: UCBRSx = 0x04
      // UCBRFx = int ( (52.083-52)*16) = 1
      UCA0BR0 = 52;                             // 8000000/16/9600
      UCA0BR1 = 0x00;
      UCA0MCTLW |= UCOS16 | UCBRF_1;
      UCA0CTLW0 &= ~UCSWRST;                    // Initialize eUSCI
      UCA0IE |= UCRXIE;                         // Enable USCI_A0 RX interrupt
    
      __bis_SR_register(LPM3_bits | GIE);       // Enter LPM3, interrupts enabled
      __no_operation();                         // For debugger
    }
    
    #if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
    #pragma vector=USCI_A0_VECTOR
    __interrupt void USCI_A0_ISR(void)
    #elif defined(__GNUC__)
    void __attribute__ ((interrupt(USCI_A0_VECTOR))) USCI_A0_ISR (void)
    #else
    #error Compiler not supported!
    #endif
    {
      switch(__even_in_range(UCA0IV, USCI_UART_UCTXCPTIFG))
      {
        case USCI_NONE: break;
        case USCI_UART_UCRXIFG:
          while(!(UCA0IFG&UCTXIFG));
          UCA0TXBUF = UCA0RXBUF;
          __no_operation();
          break;
        case USCI_UART_UCTXIFG: break;
        case USCI_UART_UCSTTIFG: break;
        case USCI_UART_UCTXCPTIFG: break;
      }
    }
    

  • I have a suspicion that something is not quite right with either the cable or board. I did have some issues a while back with CCS not being able to find the board to programme. The cable is also like 1m long! I have read the DCO clock is not that precise, and the aim is to use a higher baud rate which with some tweaking will remove those errors!

    Little progress: luckily sourced a cable about half the length, I connect through CCS terminal.. hit a few keys and CCS does not halt! (still no echo though!). My only remaining problem is USCI does not connect to the Rxd and Txd!

  • Peter Morris1 said:
    P2SEL1 &= ~(BIT0 + BIT1);

    It took a little bit time to find the real problem, change this to P2SEL0.

    But then the clock seems too slow it doesn’t give a good baud rate, make the following changes;

    //	CSCTL3 = DIVA__8 + DIVS_3 + DIVM_3;        // set all dividers
    	CSCTL3 = DIVA__8 + DIVS__1 + DIVM__1;        // set all dividers
    
          // Configure UART 0
          UCA0CTL1 = UCSWRST;
    //      UCA0CTL1 |= UCSSEL_1;                      // Set ACLK = 32768 as UCBRCLK EDIT: ACLK = 250000
          UCA0CTL1 |= UCSSEL__SMCLK;
    /*
          UCA0BR0 = 6;                              // 9600 baud
          UCA0BR1 = 0;
          //UCA0STATW |= UCLISTEN; // Enable loopback mode
        //  Baud, UCOS16, BR, BRF, BRS
        //  9600   1    6    8  0x20    - From Table 18-5 of User Guide
        // UCA0MCTLW = 15-8: BRS, 7-4: BRF, 3-1: RES, 0: UCOS16
          UCA0MCTLW |= 0x2081;                      //
    */
          UCA0BR0 = 52;                             // 8000000/16/9600
          UCA0BR1 = 0x00;
          UCA0MCTLW |= UCOS16 | UCBRF_1;
          UCA0CTL1 &= ~UCSWRST;                     // release from reset
          UCA0IE = UCRXIE;		// Enable RX interrupt
    

  • You are not going to believe this... 

    I changed the code to use SMCLK, with your alterations. Still the same result as before... I can open the terminal, type characters - nothing happens.

    I notice this line: 

    P2SEL1 |= BIT0|BIT1;
    P2SEL0 &= ~(BIT0|BIT1);

    You use '|' where I use '+'. So in desperation I try this...enter a character into the terminal, straight into the interrupt routine. Nothing comes back, and the RXBUF reads 254 (decimal) no matter what character I send from terminal. Pressing play again, programme resumes. From that point it isn't a case of sending one character = one received, I tried to count but its sometimes too many. So I'm guessing now a baudrate mismatch? (I hope!)

  • and thats when I discovered I have put BR1 = 1. Putting it to 0 corrects the issue in my previous post. 

    I swapped back to the ACLK and this also works.

    On the + versus | issue: Both actually work. I'm not sure why changing it caused the program to start working. Perhaps it coincided with knocking the connector. 

    I guess this issue is now solved! Turned into a bit of a double issue I think - the USB cable being too long and a initialisation of the UART pins. 

    Thank you very much for your help Lee! Also for the useful information regarding USB vs UART. I had a look online earlier at USB encoder chips and am pretty happy with UART/RS232/USB till the next problem! Just a query you may or may not be able to answer - is it possible to transfer data (through DMA I guess) from RXBUFF to a user specified location (ideally a ring buffer) without processor input? 

  • Was a long post but finally solved your problem, and you see don’t be too quick with stating some good TI product has blown.

    Normally using ‘+’ or ‘|’ doesn’t matter but it can happen that accidently using the same bit in a mnemonic for example 001b + 011b = 100b which is a complete wrong result, 001b | 011b = 011b which is correct, so better to learn using the OR ‘|’.

    Yes it is possible to do that with DMA, I’m not so keen about using the DMA (lot of new problems) but it depends on situation, you can save time and power with it, but in other (maybe even more) situations it’s the opposite.

  • Well I won't blame TI product - its rather annoying how hard it is to achieve something basic without some help. Every time (msp430, lm4f120 and this msp430) I have an issue getting UART communications to work. The documentation isn't particularly well set up to help hobbyist/ university projects. It really helps having someone to piece the descriptions of the different registers together. 

    I figured it was doing some addition, but the values used (0x01 and 0x02) | and + both end up to 0x03. I confirmed this with the register viewer, and no functionality changed. I suspect something to do with CCS not properly rebuilding the project - a lesson in 'clean' project I think! 

    I shall look in to it and post here when I have an issue ha! I'm only drawn to it because there are some time-sensitive SPI communications which I don't want interrupts to interfere with, but I also don't want the UART buffer to overflow. 

    Thanks again for your help and sticking with it! 

  • Just a few comments on the original code:

    “UCTXIFG” is a constant (and has the value 2). So your “if” condition is always true.
    The proper way would be
    If(UCA0IFG&UCTXIFG)
    Or (simpler) wait for the buffer to be free by doing
    While(!(UBA0IFG&UCTXIFG));

    However, your ISR is echoing incoming character unconditionally. So when main has started sending (and it always does), the ISR waits for it to be sent before sending the echo. So you might receive another byte before echoing the first (and missing every second).

    In general, it is a bad idea, to do a busy waiting loop inside an ISR. I know it is in the sample code, but this sample code is only good for plain echo and can’t easily be mixed with any other data sending.

    In any case, you should see outgoing data on TX pin if
    1) PxSEL(2) are set correctly, 2) the USCI is configured properly and 3) somethign is written to TXBUF. You can confirm this with a scope or logic analyzer..

    Are you sure you have the physical connection right? I don’t have the EXP board schematics. Are you sure you’re using the right COM port in putty?

    What about RX and TX? RX is incoming and TX is outgoing,, from the MSP side. However, other device may name it differently or not. So you might be connecting two listening and two talking pins together.
    Also, MSP RX and TX is TTL level (0V=0, 3.3V=1) while RS232 is -3V=1 and +3V=0. I tmay be that the other side uses 5V TTL levels and while a 5V TTL input notmally should accept 3.3V as high, tis is not guaranteed for all devices. And of course 5V input are a bit too much for an MSP (at least put a series 2k resistor into the line)

    Yes, shorting RX and TX on the MSP should at least cause interrupts.
    Port pin configuration and clock system init look good.

    You should use binary “|” to combine bits, not arithmetic “+”, But Leo already explained this.

  • A few comment sto the original code, as these haven't been addressed yet.

    “UCTXIFG” is a constant (and has the value 2). So your “if” condition is always true.
    The proper way would be
    If(UCA0IFG&UCTXIFG)
    Or (simpler) wait for the buffer to be free by doing
    While(!(UBA0IFG&UCTXIFG));

     However, your ISR is echoing incoming character unconditionally. So when main has started sending (and it always does), the ISR waits for it to be sent before sending the echo. So you might receive another byte before echoing the first (and missing every second).
    In general, it is a bad idea, to do a busy waiting loop inside an ISR. I know it is in the sample code, but this sample code is only good for plain echo and can’t easily be mixed with any other data sending.

    In any case, you should see outgoing data on TX pin if
    1) PxSEL(2) are set correctly, the UART ha sbeen configured correctly and 3) something is written to TXBUF.

    You cna confirm this with a scope or a logic analyzer (this is much better in finding problems than looking at a complete chain of hardware and seeing nothing.)

    Are you sure you have the physical connection right? I don’t have the EXP board schematics. Are you sure you’re using the right COM port in putty?
    What about RX and TX? RX is incoming and TX is outgoing,, from the MSP side. However, other device may name it differently or not. So you might be connecting two listening and two talking pins together.
    Also, MSP RX and TX is TTL level (0V=0, 3.3V=1) while RS232 is -3V=1 and +3V=0.
    If using TTL levels, is the othe rside a 5V device? If so, 5V input are too much for the poor MSP. Put at least 1 k series resitor into the line. On the other side, the 3.3V (if this is your VCC) of the MSP should be enough to be recognized as high on 5V devices, btu not always (see for hte high threshold on the 5V device).

    Yes, shorting RX and TX on the MSP should at least cause interrupts.

    Port pin configuration and clock system init look good.

    Leo has already made a comment about using binary “|” to combine bits, not arithmetic “+”.

**Attention** This is a public forum