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.

CCS/MSP430F5342: UART receive doesn't work anymore

Part Number: MSP430F5342
Other Parts Discussed in Thread: MSP430I2021, MSP430I2040

Tool/software: Code Composer Studio

I am using the MSP430F5342 chip on a set of boards and had previously written code that included UART communication. The board would receive a command from my computer via UART, which would tell the board to begin sending sensor data back to the computer. I had tested the code and it worked very well. I then rearranged some code and saved the project under a different name. I then did not touch the boards for a month or so.

When I recently downloaded the code, I noticed that the UART communication was no longer firing. After modifying the code to skip the UART receive check and jump straight into transmitting, I noticed that the transmit from the board worked perfectly fine. I then reverted my code back to the version that I had previously confirmed worked, and the receive still did not work. I then tried example code for a simple UART echo (posted below), and it still did not work..

I have tested these code versions on 4 different boards, using two different FET programmers and FTDI cables. I have also checked continuity on the cables, so I am pretty sure that it is not a hardware issue.. I'm wondering what could possibly stopping the UART Receive from functioning. I've tried debugging the code and setting breakpoints and stepping through the code/monitoring the registers, but the RX buffer and flags never register any data.

I had an issue with an MSP430i2021 board before that was not functioning properly, and it turned out that I needed to include a low_level_init.c to execute a _system_pre_init function. However, in the example code for the F5342, I do not see any additional files like this. I'm wondering if there's any code that I can run to reset whatever has stopped the UART from functioning properly. Any advice is greatly appreciated!

Thanks,

John

#include <msp430.h>

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

  P3SEL |= BIT3+BIT4;                       // P3.3,4 = USCI_A0 TXD/RXD
  UCA0CTL1 |= UCSWRST;                      // **Put state machine in reset**
  UCA0CTL1 |= UCSSEL_2;                     // SMCLK
  UCA0BR0 = 9;                              // 1MHz 115200 (see User's Guide)
  UCA0BR1 = 0;                              // 1MHz 115200
  UCA0MCTL |= UCBRS_1 + UCBRF_0;            // Modulation UCBRSx=1, UCBRFx=0
  UCA0CTL1 &= ~UCSWRST;                     // **Initialize USCI state machine**
  UCA0IE |= UCRXIE;                         // Enable USCI_A0 RX interrupt

  __bis_SR_register(LPM0_bits + GIE);       // Enter LPM0, interrupts enabled
  __no_operation();                         // For debugger
}

// 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,4))
  {
  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;
  }
}

  • Does reading from that pin as GPIO still work?
  • No, using the RX pin as a GPIO input or output does not work. Using the TX pin works as both, as expected.

    Any thoughts?
  • This sounds as if the pin has been fried (by ESD, or by overloading it). I guess you have to replace this chip.
  • John,

    Can you load up the typical Blinky example for this part (it toggles P1.0) and change it to the pin in question and see if it toggles correctly? If it does not, then I would agree with Clemens, that you may have an ESD damaged pin. If it does work, then i would point you to the following app note for debugging UART comms.

    http://www.ti.com/lit/slaa734
  • I can try the toggle code that you mentioned, but I have already tried a very simple script of setting the pin either to input or to output (high and low), and it did not work. The only reason I would question that the pin has been damaged is that this same activity is happening on several other copies of this board. And those boards have been tested on different computers with different FTDI cables and FET programmers, not the ones that I have tested with the board I have been mentioning here.

    And thank you for pointing me to those UART notes, I will have a look through those. But as I mentioned it had been working before, and reverting to the code that worked does not solve the issue, so I was wondering if there might be some pre_init underlying issue or something that I needed to run to reset the board.

    Thanks

  • John,

    The standard code example would take care of any pre_init issues that could be there as they are standalone projects. Typically, you should not have an issue with pre_init as it is not messed with. Module operation is independent of pre_init, typically, as it has to do with clock setup and module register initialization.

    Another thing to note is a cross check of your schematic, chip pinout, and physical connection to the board. Its a good sanity check to do to make everything is hooked up correctly. Also remember that UART connections cross from device to device. MSP430 UART TX -> External Device UART RX and MSP430 UART RX <- External Device UART TX.
  • The MSP430F534x code examples appear to just be isolated c files. Unless I am incorrectly accessing them, it doesn't appear that there are associated projects with them, so I have just been creating new projects aimed at this chip and replacing main.c with the example's associated c file content. Are there actual entire projects that I should access? Also, the examples don't have the _low_level_init that I had seen previously with the MSP430i2021. The pre_init that you mentioned makes sense though, as the issue I had seen previously with the MPS430i2021 dealt with the DCO not clocked properly.

    And thank you for your pointers, but the pinout is a keyed JST connector that can only plug in one way, and I ensured that the connections were crossed (RX->TX, etc). I understand that it sounds like the pin might be fried, but I just find it hard to believe that this happened on two sets of separated boards all of the sudden with the only link being that code that was tested.. And UART had worked previously with no wiring changes.. The pins are also only connected to the JST connector- nothing else on the board, so it's not like the code would've turned something else on that would've fried that pin or something. The modified code that seemingly broke everything was essentially the old, working code with some items just moved around and the project saved under a different name.

    Thanks

  • Hello John,

    the low_level_init you are speaking about is special to MSP430i2040 series devices.

    For the code examples, importing these within CCS will create a new project with the code example. Otherwise, you will need to create a blank project and replace the main with the code example. If these code examples are not working properly, then more than likely you have a hardware issue.

**Attention** This is a public forum