• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 732 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP-EXP430G2ET: Backchannel UART not working, but computer and MSP have same parameters

Hannah DeVore
Prodigy 40 points
Part Number: MSP-EXP430G2ET

I am trying to use the backchannel uart to talk to a computer, just to send simple data. I want to send binary, ascii, or something similar, basically just some sort of simple data. I have configured all of the UART stuff, and it works great in loopback mode, so that the receive and send values are what I expect. However, when I take it out of loopback mode, I cannot get it to talk to a computer (currently using MATLAB to control the USB ports). Using an oscilloscope to debug, the RXD pin doesn't fluctuate at all, even when the computer sends data. The TXD pin can send data, and the scope shows the expected pattern of behavior, but the computer does not appear to receive it. Oddly, though, when the computer sends data, the TXD pin sometimes becomes noisy (the high and low values have rapid fluctuations in them, while still clearly following the pattern and timing of the signal its supposed to be sending).

Both the computer and MSP are configured to 9600 baud rate, even parity, MSB first/big endian, 8 bit data, 2 stop bits.

I'm 90% sure that the RXD and TXD pins are multiplexed to the correct peripheral.

Why do neither the MSP's signals nor the computer's signals seem to reach the other device? Since I don't get any signal on the RXD pin at all, does that mean the issue is on the MSP's end?

Thank you!

Here's a file with my code

InterfaceToUSBpractice.zip

  • 0
    Guru 95280 points

    When you put the RXD/TXD jumpers back on J101, did you rotate them 90 degrees from all the other pins? There's a guide on the silkscreen just to the MCU side of J101 -- you want HW-UART.

    This is a convention from the ancient days, and only (as far as I know) on the G2 Launchpad(s).

  • 0
    TI__Genius 17960 points

    Hello Hannah,

    if you remove the jumpers for the UART (RX/TX) back channel at J101 any potential HW conflicts should be removed. In this state, you should see on the PC/eZ-FET side the clean TX signal from the PC and vice versa on the MSP430 side the clean TX signal from the MSP430 in the case when you're transmitting from MSP430. This way you can also check whether you need to flip RX/TX or not.

    If not seeing the TX signal on the PC side, the root cause might be not selecting the right COM port. Please check the HW manager for the COM port of the LP. This should show up twice, once as debug interface and once as COM port. The number of the COM port needs to be selected in whatever tool you're trying to use to send data to MSP430.

    Best regards

    Peter

  • 0 in reply to Bruce McKenney
    Prodigy 40 points

    Wouldn't turning the jumpers 90 degrees just tie RXD and TXD together?

  • 0 in reply to Hannah DeVore
    Guru 95280 points

    This would be true of the other Launchpads, but not the G2 and G2ET. These Launchpads are the only ones that accept DIP packages, and some variants of those have only a software UART.

    On the G2 and G2ET, to use the hardware UART, you need to rotate the jumpers 90 degrees -- matching the "HW-UART" mark on the silkscreen.

    I was a bit surprised that I couldn't find this mentioned in the G2ET User Guide (SLAU772). (I've just submitted a document bug report.) The scheme is shown in the schematics [UG p. 23, section "Target Connector"], but I agree that's non-obvious. I'm pretty sure the jumpers come set that way from the factory.

  • 0 in reply to Bruce McKenney
    Prodigy 40 points

    Thanks! turning the jumpers did fix a lot of the problem -- I have signal on my RXD pin now!

    However, the two devices appear to be trying to communicate at very different speeds. an oscilloscope shows that signal on the RXD pin is nearly 1000 times faster than the signals on the TXD pin. I think my TXD is too slow, but I don't know why (it takes a total of like 325 ms to send an 8 bit value, including the stop and parity bits and whatnot). I've double checked my baud rate control values -- I got the values of UCAxBR0, UCAxBR1, and UCAxMCTL from line 12 on the table on pg 424 of the MSPx2xx data sheet, and sourced BRCLK from SMCLK. The only thing I can think of causing the issues would be a problem with SMCLK, but an oscilloscope seems to give me the correct frequency (I am using DCOCTL = 0x0026   and  BCSCTL1 = 0x0027  because they experimentally gave me 1MHz, because the definitions of CALDCO_1MHz and CALBC1_1MHz gave me errors despite being defined, and using their definitions of 0x10FE and 0x10FF gave me truncation warnings and a clock speed of 20 MHz). 

    How come my signal is so slow? Is it possible there is an error with my clock speed despite measuring it with an oscilloscope?

  • 0 in reply to Hannah DeVore
    Guru 95280 points

    > UCA0BR0 = 104;

    > UCA0BR1 = 104; // UCBRx = 104

    The second line should be

    > UCA0BR1 = 0; // UCBRx = 104

    BR1/BR0 are the high/low bytes of a (16-bit) word called in other devices UCA0BRW. This change makes the high byte (BR1) 0 so BRW=104.

    I haven't audited your other "0b" bit strings. <msp430.h> supplies names for all these bits, which makes it much easier to debug.

**Attention** This is a public forum