Uart TX not working


I am trying to get UART working on my jetson nano. More specifically im seemingly not able to transmit anything over UART to some Sabertooth motor controllers. I have followed this guide: with regards to transmitting in python3 and entering the stop and disable commands. I’m using the older jetson nano with only one camera port if that’s any help.

My sabertooth code is here although I forgot to commit the latest code with the serial .write() method and will update it when i get on my laptop. It is copy and pasted the exact same settings from the jetson hacks demo example.

I have tried/tested:

Using an NI-myRIO to control my sabertooths and both work (sabertooth is programmed to 115200 baud and its addressing are configured right)

tried communicating directly with the myRIO (jetson can recive myRIO transmissions, myRIO cannot read Jetson transmissions)

tried slower baud rates like 9600

tried a voltage level shifter (per documentation: sabertooth expects 5v signal, however will act on 3.3v; tested on myRIO which also outputs at 3.3V)

grounds are tied together

I suspect some kind of software issue as I’ve had this problem for a long time and tried it when I bought the nano brand new and it didn’t work. Asking on the forum now because I am fully lost as to what could be the issue, even though this seems like a hardware problem. My question then is: is there any way of confirming in software that it should be functional? I do not have access right now to an electronic testing equipment like an oscilloscope to electrically check the signal, but do measure 3.3v with a multi-meter on the tx pin.

I have not connected the Tx pin to anything else other than the myRIO and sabertooth, and tried to get it working when it was brand new which is why I don’t suspect a hardware issue but cannot be certain.


hello kaitallaoua,

Please refer to Nano J41 Header Pinout and confirm the pin connection, you should wiring to pin-8 and pin-10 for Tx/Rx and also GND pins.
it’s default serial console using baudrate as 115200/8n1, you may enable terminal to check the messages via ttyTHS1.

I am having the exact same problem as @kaitallaoua where I am having trouble using ttyTHS1 on my nano. I am using the dev board, and the target is an Impinj RS1000 module. I have confirmed the RS1000 module works perfectly when using a USB-serial converter. However when I try direct UART communication with the nano via J41 pins 8/10, the RS1000 is not receiving any communication from the nano (but works fine in the other direction - i.e. when I connect to the debug UART on the RS1000, I can read the messages just fine). I have confirmed that the nvgetty service is not running on my nano. I’ve tried many different baud rates and also confirmed wiring is correct (the RS1000 module receives both power and ground from the nano, and grounds are tied). Are there any troubleshooting steps for serial communication? Below is the datasheet for the RS1000, with serial specs on p.11 - which appear to be in line with the expected values for the nano, including voltages and Rpu. I’m wondering if the nano communicating at 1V8 and not 3V3? I read some other posts about a level shifter being needed, but I thought 3V3 (which the RS1000 uses) should be fine. Is there a way to confirm the nano is in fact communicating at 3V3?

3.3V for serial console.

@linuxdev thank you - do you know if that is the case for the serial connections on both J50 (ttyS0) and J41 (ttyTHS1)? I read something about different Rpu on those interfaces leading to differences in how the level shifters work.

I can’t guarantee for all carrier boards and UART interfaces, but all of the ones I know of on Jetsons are all 3.3V. Different carrier boards may have different level shifters, and the modules themselves may be 1.8V, but it is the carrier board you have to go by (and that is 3.3V).

I don’t know for sure what the RPi uses, but I do remember once seeing a USB serial UART with 3.3V interface advertising RPi compatible.

@linuxdev I am using the jetson nano dev kit rev B01 carrier board - do you happen to know how the level shifters work on this board?

For GPIO there might be a selectable jumper, but for the serial console it should be fixed at 3.3V.

OK, I guess I’m back at square one then, since the device I am connecting is 3.3v. Serial communication is not working over UART on my nano using the B01 carrier board. @kaitallaoua were you able to get yours working?

No I was not sadly. I’ll have to find the other forms but people were saying it could be an encoding issue? In the end I used an arduino for my project for the TX and other stuff but I was just going to use a USB to UART adapter which people said works on the jetson.

Thanks for the info - so @JerryChang it seems this thread has been incorrectly marked as solved. I agree that the nano works fine with USB-UART converters, I’ve got it working with my Impinj RS1000 module using a FTDI FT2232D chip with no issues. But we are building a custom board around the nano, and with three UART ports the nano should not need to use a USB-UART converter which adds both cost and complexity.

Is there anyone from Nvidia who can help with this issue? Are there any settings or other configuration options to get the B01 carrier board working with a 3.3v UART device natively, without using a USB-UART converter?

1 Like

One further thought on this- I just tried connecting ttyS0 to ttyTHS1 and it appears that ttyS0 is outputting dmesg logs. Is this some kind of built-in functionality with the L4T package? How can I disable this? I am wondering if this is causing the issues - at least for when I try using ttyS0.

ttyS0 is the serial console. Look at these permissions:
ls -l /dev/ttyS0
…if tty is the group, verus dialout, then the tty is already being used by nvgetty.service (a terminal program). You would need to first disable serial console before you could use this.

If you only connect to this tty after boot, then you can simply:
sudo systemctl stop nvgetty.service
sudo systemctl disable nvgetty.service
…or restart it:
sudo systemctl enable nvgetty.service
sudo systemctl start nvgetty.service

The trick is that this console is also used in boot stages prior to the Linux kernel starting. Hitting any key at certain points in boot will halt boot. You would have to look up separate steps to disable this in boot stages if you use this and your device has activity at the wrong moment (meaning it would halt boot).

FYI, ttyS0 is the same hardware as ttyTHS0, but different drivers. The reason ttyS0 is used instead of ttyTHS0 is because the older driver which produces ttyS0 is available in boot stages, but the DMA-enabled ttyTHS0 driver does not exist in early boot stages.

This is so much easier to debug if you have an oscilloscope.

I was able to disable the ttyS0 getty service, but I’m still having the same issue - I can read from serial devices just fine (i.e. the RX on the nano is working) but I can’t write to them (TX not working). I have tried multiple nano’s now (since the first one I had needed to be replaced for unrelated reasons) and I have the same issue - TX not working. I’ve tried using both ttyS0 (J50) and ttyTHS1 (J41) and it’s the same issue. RX works but not TX. Does anyone have any ideas what could be causing this odd behavior?

@nvidiadev1 tell me about it…I think I might buy one just to get to the bottom of this problem.

** UPDATE ** I suspect it has to do with the issues outlined in this thread and if so I am out of luck unless I can figure out a solution that can correctly trigger the TXB0108 level shifter to output at 3.3v – or move to a custom carrier board that uses a different level shifter. @kaitallaoua you might be interested to see this as well, assuming you still have interest in using the nano for your project.

1 Like

I’m having a similar problem with the Jetson Xavier NX, which was working fine until a few days ago, but TX stopped working all of a sudden on Monday.

On the Nano I manage to send the data both ways but its scrambled.

The Nano and NX have the same carrier board, but you should probably start a new thread in the NX forums, and then give a reference to this thread.

For the other people, it would indeed be useful to have an oscilloscope to verify voltage levels.

1 Like

Hey @linuxdev here is the new thread I opened in the NX forums: Unreliable serial communcation via the UART TX/RX GPIO Pins

Just added a reference to this thread as well.

Also, the carrier boards on my Nano and the NX seem to be quite different.