UART on jetson xavier nx

I am trying to established uart communication between jetson and esp32 module .
I have made connection as pin8 TX (jetson)-- RX2(esp),pin10 TX (jetson)-- TX2(esp) , and a gound is common .
jetson is master and esp32 is slave . I have tried esp to esp uart ,it worked . I tried laptop to esp ( using pyserial ) it worked . so i feel there is issue in how jetson pins or their declaration .
following is the jetson code
import serial

Setup UART 2 for sending data to the receiver ESP32

ser = serial.Serial(
port=‘/dev/ttyTHS1’, # The UART device
baudrate=115200, # Baudrate
timeout=1 # Read timeout
) # Adjust port and baud rate as needed
try:
while True:
message=input("enter the message : ")

        # Send the message via UART 2 to the receiver ESP32
        ser.write((message + '\n').encode())  # Send the message over UART2

        # Print confirmation back to the PC
        print(f"Sent: {message}")

except KeyboardInterrupt:
# Close the serial ports on exit

ser.close()

would you tell me how to check if esp32 has gotten connection with jetson or is there any other way to established uart between them

What do you see from “ls -l /dev/ttyTHS1”? Is it group “dialout”, or is it group “tty”? If the former, then you can use that port. If the latter, then you cannot use that UART until disabling the serial console (the latter case is when some other process is already using the UART; in this case, the serial console).

You can disable serial console (not needed unless it is group tty):

sudo systemctl disable nvgetty.service
sudo systemctl stop nvgetty.service

Note that this disables it only once Linux is running. You might find output during boot stage as well, and stray input to the UART during boot (if still enabled in boot) may halt boot and send you to a serial console prompt.

I tried doing this yet again the uart communication was not established how to debug it

Does the ttyTHS1 you are using show group “dialout”? I’m guessing yes, but what I suggest is to test it in loopback mode.

Loopback on a serial UART means simply shorting the TX pin and RX pin together. The UART now talks to itself. If you have flow control enabled, then you’d also connect CTS and DTS. Any serial console type program would then echo whatever you type without enabling “local” echo. I like gtkterm (“sudo apt-get install gtkterm”), but you could substitute. Settings by default are 115200 8N1 (I see the speed set in your code, and most likely the default is 8-bits, no parity, and one stop bit, but I won’t guarantee that in your Python). Example of that UART talking to itself and echo:
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyTHS1

Note that although you could use user “root” via “sudo”, you can also add your user to group “dialout” if you have permission issues. If your user name is “hydro”, then you can add that user to group “dialout” via:
sudo usermod -aG dialout hydro
(then you no longer need sudo)

When you type into your terminal, do you see echo?

Note that the Jetson will use 3.3V levels, and so if an external device is the wrong level, then it may work in one direction, but not in the other direction (or it might not work at all). Be certain your device uses 3.3V logic.

Assuming loopback works, and that the esp32 is 3.3v logic, then the only issue which would be likely to be a problem is if the UART settings are incorrect (the speed 115200, the data size 8-bit, the “no parity”, and the one stop bit).

are you suggesting to short these pin 8 and pin 10

Yes. And then “aim” your serial console program at the correct “/dev” file. See if it echoes back when you type, and when “local echo” is not enabled. The settings default settings would be 115200 8N1 (no CTS/DTS flow control). UARTs usually agree with themselves on settings (it is possible under rare circumstances they won’t), and they always agree about signal levels. Noise is minimal with such a short “cable”. That’s loopback, and it is perhaps the number 1 tool for verification since it only involves half of the information.

If that works, then it is simple to make a Python script to test echo to and verification of data from a loopback UART. If all is well, then you pretty much know any error is related to the combination of this UART and the remote UART (e.g., cable noise, signal levels not being correct, speed settings wrong, so on).

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.