Weak UART TX Signal From Orin NX

[noah.g]

I am having a problem right now where I am unable to get 2 way communication on the UART device /dev/ttyTHS0. To give some context into the setup I am running and have experimented with, we are running a custom sensor board which uses UART to communicate to and from an Orin NX devkit. The devkit is built up of a 16GB Orin NX module and an official Nvidia carrier board (although we have experimented with a knockoff {Yahboom} carrier board with the same results). We do not use flow control and we use relatively normal settings for the UART communication (460800 BAUD, 8 bits, 1 stop bit, no parity).

The problem being experienced here is that while we are able to receive messages from our custom sensor board without issue, we do not seem to be able to send messages to it. We have tested the exact same setup with our Xavier AGX systems, and they are able to communicate bi-directional with the sensor board with no issues at all. We have used the same wires, sensor board, sensor board firmware, and basically everything. The only variable we have changed is the replacement from Xavier AGX to Orin NX.

I have confirmed that the messages are being sent from the Orin NX by instead connecting the UART TX to a “debugger” which allows me to read the UART messages on the wire in a console. I have confirmed that the Orin NX is sending messages and they can be read when plugged into the debugger.

I have also observed a phenomenon while examining the signal under an oscilloscope. I will include 2 photos below showing the problem I am observing. In one photo we can see the system with the Xavier AGX connected to the sensor board. We can see the UART connection is healthy and the voltages are regularly going between 0 and 3.3V as expected in the UART communication. When I then switch the connection to the Orin NX system, we can see that the TX signal (yellow) is constantly pulled high and seems to be struggling to send any meaningful signals to the sensor board.

In the following images the blue line is the Orin NX / Xavier AGX’s RX and yellow is TX. The zoom factors are exactly the same and the voltage levels for each line is the same.

Xavier AGX connected to sensor board (Orin NX is not connected):

Orin NX connected to same sensor board with same wires (Xavier AGX has been disconnected):

I am not sure how to proceed with debugging this any further. If anyone knows of any setting I can configure in the kernel or the device tree I would be happy to give it a try. It seems that something on the Orin NX is causing the TX line to be constantly be pulled high. To hopefully speed things up I have attached a copy of the boot log and the device tree on my device.

device_tree.txt (428.5 KB)
orin_nx_boot.txt (90.7 KB)

Thank you,
Noah

[noah.g]

I am also aware of this topic which is opened right now. I am not sure if it is relevant but I will link it in case it is similar to the problem I am facing.

Jeston Orin nano TX pin not working? - Jetson & Embedded Systems / Jetson Orin Nano - NVIDIA Developer Forums

[KevinFFF]

Hi noah.g,

What’s your Jetpack version in use for Xavier AGX and Orin NX respectively?

Which UART interface are you using for Orin NX?

[Trumany]

Are you using UART1 of 40-pin header? There are load requirements for the pins since they go through a level shift. Please refer to this doc first.
Jetson Nano Developer Kit 40-Pin Expansion Header GPIO Usage Considerations Applications Note

[noah.g]

The Xavier AGX is using Jetpack 4.6.4 and the Orin NX is using Jetpack 5.1.3.

I am using the uart1 interface on the 40 pin header.

[noah.g]

Yes I am. I will take some time to review this document. In general, do you know if the load requirement for the Orin NX is the same as the Xavier AGX (or Orin AGX) developer kits?

If there load requirement is different, do you know of a potential workaround I can implement to get my device working? I would like to avoid additional hardware if possible, but if it is impossible to work around without a different piece of hardware, I would be willing to try it.

[Trumany]

Any pin that goes through the level shift has same load requirement as listed in the doc. No work around on the pins if external device can not fullfil the requests.