UART communication read not working

I’m just started using the NVIDIA Jetson TX2 and trying to use it in a robotics project. I’m using serial addressed motor controllers and previously was using a Raspberry Pi to do UART communication to each of them.

I’m using the Jetson TX2 Development board, and have successfully been able to send out serial commands on the J17 connector (pin 2 as TX pin 3 as RX) to both the motor controllers and to a Raspberry Pi. I’ve verified on each of these that the command received was the correct command exactly. However the serial read line on the Jetson always hits a timeout, and never reads anything back. I further used minicom and did a loopback test of connecting J17 pin 2 and 3 and using minicom to test, which didn’t read anything. My minicom parameters are as follows:

Serial device : /dev/ttyTHS2
Lockfile location : /var/lock
BSP: 115200
Parity: N
Stopbits: 1
Hardware flow control : no
Software flow control : no

Again this yields nothing on the read line, but if i take that exact line and plug into a Raspberry Pi I am able to read the serial commands.

Am I missing anything to make the UART read line work?

The serial UART doesn’t like CTS/RTS, I suppose if this is connected it could interfere (even if this is disabled in software you might make sure the wires are not connected)…but your basic parameters are correct.

One thing which throws lots of people off is if wiring isn’t sufficient quality. A short jumper between TX and RX won’t be an issue, but if for example you’ve connected a wire from J17 to another board and the wire isn’t twisted pair, then you may have noise issues. Shielded is even better. Ethernet cable is a really good way to go.

Also, J17 is 3.3V logic level. Make sure whatever you are working with is 3.3V.

The only wires I have plugged into the J17 connector is pin 2 and 3 right now, so shouldn’t have to worry about CTS/RTS unless there is some other setting to get the hardware ready to receive. Also currently I am just trying to test it with a loopback test by plugging J17 TX (pin2) directly to J17 RX (pin3) by a short jumper, so voltage logic level and noise I would expect not to be an issue.

The strange part is that I have verified that I am writing out correctly over the TX line by testing with a Raspberry Pi. But when I just exactly the same thing and just move the TX line from the Raspberry Pi back to the RX line on the J17 connector I only get a timeout

You have the wrong pinout. On the 6-pin serial UART connections, function by pin number (relative to host side) is:

  1. Ground.
  2. CTS
  3. +5V out (USB power line)
  4. TX
  5. RX
  6. RTS

To loopback data, pins 4 and 5 are connected. To loopback CTS/RTS, pins 2 and 6 are connected (you probably don’t want CTS/RTS on a TX2).

Pin 2 to 3 applies +5V to the 3.3V CTS. I doubt this would damage it, but it could, and would definitely fail loopback.

Ah I was looking at a post where someone had used the TX2 to communicate to a different device, and maybe the way he described the pinout is backwards of what it is.

I am testing the loopback on Pin 4 and 5 as you described above. I do however believe that in your above description pin 5 is TX and 4 is RX. I unplugged pin 4 and am running pin 5 to my Raspberry Pi currently am reading correctly onto the Pi

On the cable RX and TX reverse…it depends which end you are looking at. I’m looking at the schematics to the carrier board. On the board pin 5 is RX, but on the mating cable pin 5 is TX.

I see what you’re saying. Either way though the loopback test across pin 4 and 5 should be correct, however cannot figure out why I am not reading anything back in.

I’d consider the possibility of damaged hardware from touching the +5V rail to the CTS pin. I’m just guessing when I say there is a good chance a momentary +5V (instead of 3.3V) wouldn’t harm anything, but chances of damage go up when it is a sustained long term +5V (though even then it might not have cared, but it is a possibility that needs to be mentioned).

I have found minicom to not necessarily be reliable unless you know the configuration has worked before. My reason for saying this is because minicom was designed for modems, and as such, can have configuration for sending modem init strings or to do other conversion you are not expecting when working on a pure serial port and not a real modem. You might try gtkterm. For my test case this works when logged in as user “ubuntu” (since “ubuntu” is a member of “dialout”…user “nvidia” is also a member of “dialout”) and shorting pins 4 and 5:

gtkterm -p /dev/ttyTHS2 -s 115200

I think there was just a little bit of confusion earlier in what I was calling the pins based on the information from a different source. I had always been using pins 4 and 5, and was just calling them pins 2 and 3 based on the naming from that guide.

I tried using gtkterm to preform the loop-back test, and it yielded the same result as minicom. I tested it using the Raspberry Pi to make sure gtkterm was outputting UART command and it worked.

At this point I’m suspecting that there might be a hardware issue though. Do you think it is best to try and use the J21 instead? I think that appeared to be tied to the serial console, I think the requires a little bit to change but am not exactly sure all what goes into trying to make that work for UART instead.

Disabling serial console to use as a regular UART is actually a lot of work and not simple (it involves kernel arguments, device tree, and edits to U-Boot since it isn’t just Linux using this as a serial console).

I think sometimes people get a device to use with the port which is the wrong logic level (not possible to be in error with loopback), or else load it down with something requiring too much current (the UART isn’t designed to directly drive some circuits which I think an RPi can drive…but this too is not a possible condition with loopback).

The camera which comes with the carrier board (along with the software) does not normally interact with the J17 serial UART. However, the J17 wiring does go to this camera (some users might want this for custom solutions). On the off chance that something dealing with the camera is interfering you might try with the camera removed (it’s just a couple of small phillips head screws and a socket).

In the case of loopback failing with the above test in mind using gtkterm I suspect it really is a hardware failure. If the device has not been flashed to a recent L4T version, then I would suggest to first try flashing. If flashing doesn’t get past the issue I suggest going ahead with RMA. If this is the case you can find RMA information near the top of this:

I had unplugged the camera a while ago reading something similar to what you just said yeah, and I had very recently flashed the newest version L4T version. It does seem like the RMA is potentially the option at this point.

Thanks for your assistance on this issue, I appreciate it a lot

The stock camera does not interfere with the serial port.
The circuitry on the carrier board isolates the 3V serial output when the camera demands serial I/O through a signal, but that signal is not set on the stock camera.