I am attempting to establish UART communication using a Jetson Nano. The device’s TX and RX pins are connected to pins 8 and 10 on the Nano, respectively. I have been supplying power through a power supply at either 5V or 6V. While I had success with transmissions using RS232, I am encountering issues when connecting the device directly to the Jetson Nano.
I have employed the following Python code to verify the connection:
import serial
import serial.tools.list_ports
def check_device_connected(port_name):
ports = list(serial.tools.list_ports.comports())
for p in ports:
if p.device == port_name:
print(f"Device connected on {port_name}: {p.description}")
return True
print(f"Device not found on port {port_name}")
return False
check_device_connected(‘/dev/ttyTHS1’)
When I run this code to check for a connection, I receive an error indicating that the device cannot be found on the ttyTHS1 port.
To reiterate, the device’s TX and RX are connected to the Nano’s RX and TX pins, respectively, and the power is provided by a power supply. Everything functioned correctly when using an RS232, but I am unsure how to proceed with a direct connection to the Jetson Nano.
Could anyone provide guidance or suggestions on how to resolve this issue? Any assistance would be greatly appreciated.
Important: You don’t supply power to the Jetson over any of the serial UART connections. You might want to describe what you mean by supplying 5V or 6V. The USB power to the Nano is something in compliance with USB specs, and 6V is too much for that. Most of the time I see 5.2 to 5.25V.
RS232 is actually a specification of both the PHY and the protocol. Jetsons (other than the old TK1 which has a DB-9 connector) don’t use the RS232 PHY. You could just call it a serial UART (3.3V level exposed on the carrier board, sometimes known as a TTL level).
First, is that port available? Use “ls -l /dev/ttyTHS1”. If the group is “dialout”, then you are in luck. If not, then it will be “tty”, and that means you’re using a port already owned for serial port login. You’d have to disable serial console (not usually advisable, but if nothing is failing you might not need serial console) if that is the case (also removing some debug tools). To temporarily disable that port: sudo systemctl stop nvgetty.service
If you want to disable the serial console, including across reboots:
Please note that the above only disables serial console while in Linux. Earlier boot stages till use that port for serial console if that port was group tty. In that case, if the port sees activity in boot stages, it would halt and wait for input thinking your device is a serial console. If boot doesn’t see activity, and if your device is not listening while booting, then that would be all you need to do.
If that port is already group dialout, then it should work. Note that the default setting is 115200 8N1. CTS/RTS control flow is disabled by default.