Jeston Orin nano TX pin not working?

I’m trying to connect my Jetson Orin nano to a flight controller (Cube Orange +) with a serial connection with the command : “ --master=/dev/ttyTHS0” and i have this result:

So what i understood is i can receive a heartbeat from the flight controller (flight controller’s TX is sending a signal to Orin’s RX!), but I can’t send anything from the Orin to the FC (i think this means there is a problem in the connection between the Orin’s TX and the flight controller’s RX!).
If you have already a similar problem or have more questions about the problem don’t hesitate to contact me for more informations.

Hi mohamedaminefaiz82,

Are you using the devkit or custom board for Orin Nano?
What’s your Jetpack version in use?

Have you verified the UART loopback test through shorting TX/RX?

Have you checked if there’s any signal from TX of Orin Nano after you send the data?

Hi KevinFFF,

I’m using the devkit Orin Nano with a 5.3 Jetpack version.

For the UART loopback test, it seems like it’s working (when i type a caracter on the keyboard, the same caracter is typed in gtkterm!).

Honestly, i didn’t check if there is any signal from TX, because i don’t have an oscilloscope nor a voltmeter. But it has already worked in the loopback test, so I don’t think it’s the problem.

I have tested the same command with a USB-UART adapter (/dev/ttyUSB0) and i have this in Terminal:

But for my projet I don’t have the space to add another component, so i should use the /dev/ttyTHS0

So, is the issue specific to the serial communication with your flight controller?

Please share your device tree for further check.

Hi Kevin,

Sorry for the late response (I was on a vacation!).

The issue is that the TX pin in the Jetson Orin nano is not sending anything to the flight controller.

Here is the device tree that i got with the command :

dtc -I fs /sys/firmware/devicetree/base

device_tree.txt (421.3 KB)

One thing to consider: You know it is sending because of loopback. What you don’t know is if the other side is listening, or if the logic levels are correct. Normally a UART will agree with itself on settings during loopback. Levels are guaranteed to be the same. The UARTs you are looking at by default will be at a 3.3V logic level. Can you check if the UART at the other end is 3.3V? This is likely correct, but it might not be. If voltages are wrong it is unknown if there will be errors, but usually too much send strength might result in send (or hardware failure), and too low of a send strength would almost always fail.

Second, there are different forms of flow control. You might see the normal situation without flow control, but there is a possibility that the side sending is indeed sending, but not using flow control, and thus if the receiving side demands flow control, will ignore what is sent. Can you check your other end to see if it expects flow control?

Basically, if flow control is enabled, then the the RTS (request to send) must be asserted before the sender can send; the sender then asserts CTS (clear to send) if it is ok to send. When both assert data is sent and received. If the buffer at receive fills up, then CTS de-asserts. RTS will remain asserted if there is more to send. When CTS re-asserts (assuming processing buffer data finished), then both CTS and RTS agree and the sender continues sending. If sender runs out of data, then it de-asserts RTS and stops sending.

Many many UART designs ignore and do not use the CTS and RTS wires. It is software though which sets or removes the CTS/RTS flow control requirements. Knowing what the other end expects is critical. Jetsons default to not using CTS/RTS flow control

1 Like

Your device tree seems not complete.
I can’t find serial@3100000 in your file.

Please share /boot/dtb/kernel_XXX.dtb for further check.

Hi linuxdev,

Thanks for your reply.

Excellent remark, it was all about the logic level of the flight controller’s RX pin.

I found a parameter in the Cube Orange + that can add a pull down so i can have the same logic level of the Jetson Orin’s TX pin.

I also want to thank KevinFFF for his support.