• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 1651 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LC4357: Issue with SCI1 Rx line. Pulls input high.

Timothy Canham
Intellectual 440 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Here is our scenario. We are using the Launchpad dev board, and we are trying to communicate with another processor via SCI1. We have an external wire loopback test that works when we connect UA1TX to UA1RX and we flow data. We also have verified that UA1TX to our processor's RX works fine. When we hook up our processor's TX to UA1RX, the signal gets pulled high and stays high when we are transmitting data from the processor to UA1RX. We have confirmed that we are sending data by scoping the processor TX when it is disconnected. It is a little baffling since the loopback seems to work fine. We have scoured HalCoGen trying to find a setting that could be causing this, but we can't find anything. We tried turning off the pull-ups for the input, but it didn't help. We confirmed that it isn't just an issue with the one processor by taking a USB->TTL adapter and connecting it. We see the same result.

  • 0
    TI__Guru 59540 points
    Hello Timothy,

    What is the source of UA1TX/RX. i.e., what device are these pins from? Have you tried the MCU hooked up in loopback mode? Are you performing any level shifting between the two devices? Generally speaking, this would only happen if one or the other device is driving the line high or if there is a very strong pull-up on the line.

    Just to confirm, you are able to receive data on the Hercules MCU from the external device (MCU RX connected to UA1TX)? If you connect a voltage source to UA1RX input, can you measure the required current to drive this signal low? i.e. start with a nominal 3.3V level and drive it low while measuring the current sourced from the voltage source.
  • 0 in reply to Chuck Davenport
    Intellectual 440 points
    The MCU in the above description is the TMS570. As I mentioned above, we have tried sending data from two sources: An external processor (An ARM based embedded computer) and a USB->TTL UART adapter connected to a PC. Both have the same symptoms in that they receive from the TMS fine, but their output gets clamped when connected to UA1RX. As I mentioned, we did some loopback with a wire on the TMS and it works fine. So to your question, we are receiving data FROM the TMS fine, we just can't send data TO the TMS. BTW, this is true for SCI3 as well.
  • 0 in reply to Timothy Canham
    TI__Guru 59540 points
    Timothy,

    This is puzzling because the TMS RX pin is an input and does not drive anything. In fact, the output buffer for the pin would be completely disabled under this condition. The pulls are irrelevant as they are very small and can be driven high or low with very little current. Note that Hercules is not truly a UART implementation so I am assuming there is something related to this that is causing this issue since the devices you are connecting to are probably true UARTs and not simple SCI modules. Are you using a UART transceiver in your circuit? Can you the signals going in vs coming out on the MCU side?
  • 0 in reply to Chuck Davenport
    Intellectual 440 points

    I had a co-worker who suggested that the JTAG UART port is interfering with SCI1 on the Launchpad. Would that be a possibility?

  • 0 in reply to Timothy Canham
    TI__Guru 59540 points
    Timothy,

    I discussed this with the designer of the board and, although LIN/SCI1 is connected to the XDS110 MCU to be used as a virtual com port, there are no reasons to believe that this interconnect would impact the use of the UA1TX and UA1RX pins. With that said, I am not certain how much this was tested.
    Given this, I would advise to use an alternate SCI if you can, but I thought you had mentioned that you saw the same phenomenon on the SCI3 (UA3TX/RX) pins.
  • 0 in reply to Chuck Davenport
    Intellectual 440 points

    To follow this up, there was a coding error that made SCI3 not work. When that was corrected, moving the connection to SCI3 (UA3) worked in both directions, while SCI1 did not. We'll test again when we have the MCU on our own board without the built-in JTAG adapter.

  • 0 in reply to Timothy Canham
    TI__Guru 59540 points

    Hello Timothy,

    Thanks for the follow up. Please let us know if you continue to have issue with SCI1 on your new custom board.