ttyTHS1 (UART1, 40-pin header pins 8/10) TX pad does not drive on JetPack 7 / L4T R39.2 — Orin Nano Super devkit

consultingfutures · June 14, 2026, 8:54am

Summary

On a Jetson Orin Nano Developer Kit (Super), freshly on L4T R39.2 / JetPack 7, I cannot get the 40-pin header UART (UART1 / /dev/ttyTHS1, pins 8/10) to transmit or receive. The controller probes cleanly, the pinmux reports function uarta at the register level, and the device-tree pad config is correct — but the TX pad (PR.02 / pin 8) never drives (measures ~0.3 V on a meter instead of idling at 3.3 V), and a TX↔RX hardware loopback returns no data at any baud.

This looks distinct from the known JetPack 6.2.2 DMA issue (Solved: UART/Serial Port not working after upgrading to JetPack 6.2.2) — I applied that fix (forced PIO) and the behavior is unchanged.

Question: Is ttyTHS1 on the 40-pin header functional on R39.2 for this board, and is there an additional pad/prod-setting required that jetson-io does not apply on R39?

Environment

# /etc/nv_tegra_release
# R39 (release), REVISION: 2.0, GCID: 45755727, BOARD: generic, EABI: aarch64, DATE: Mon Jun  1 09:28:48 PM UTC 2026
# KERNEL_VARIANT: oot

Model:  NVIDIA Jetson Orin Nano Engineering Reference Developer Kit Super
Kernel: Linux 6.8.12-1021-tegra #1 SMP PREEMPT aarch64
TNSPEC: 3767-300-0005-T.1-1-1-jetson-orin-nano-devkit-super
Board:  p3768-0000 + p3767-0005 (Orin Nano 8GB Super)

Console is on ttyTCU0 (USB-C debug). The 40-pin header UART is free (nvgetty inactive, nothing holds /dev/ttyTHS1).

Goal

Use the 40-pin header UART (pins 8 = UART1_TX, 10 = UART1_RX) as /dev/ttyTHS1 to talk to an external 3.3 V TTL device.

Steps taken

Enabled uarta on the 40-pin header via jetson-io.
sudo /opt/nvidia/jetson-io/jetson-io.py → Configure 40-pin Header → set pins 8/10 to uarta → Save and reboot. This created /boot/jetson-io-hdr40-user-custom.dtbo and a JetsonIO entry in extlinux.conf (FDT + OVERLAYS), set as DEFAULT.
(Note: the headless config-by-function.py -o dt uarta route wrote a modified DTB but did not wire it into the boot chain — only the interactive tool added the OVERLAYS line. Possibly worth documenting.)
Applied the known JetPack 6.2.2 DMA workaround (remove dmas/dma-names from serial@3100000 to force PIO). Confirmed in dmesg the UART now runs in PIO mode. No change to the symptom.
Noticed jetson-io set nvidia,gpio-mode = <0x01> on both UART pins in the generated overlay — a property no other pin in the live tree carries. I rebuilt the overlay with gpio-mode = <0x00>. No change to the symptom.

Current state — everything checks out, pad still dead

dmesg — controller probes cleanly in PIO mode:

serial-tegra 3100000.serial: Adding to iommu group 1
serial-tegra 3100000.serial: RX in PIO mode
serial-tegra 3100000.serial: TX in PIO mode
3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 133, base_baud = 0) is a TEGRA_UART

Pinmux register state (/sys/kernel/debug/pinctrl/*/pinmux-pins):

pin 110 (UART1_TX_PR2): 2430000.pinmux (GPIO UNCLAIMED) (HOG) function uarta group uart1_tx_pr2
pin 111 (UART1_RX_PR3): 2430000.pinmux (GPIO UNCLAIMED) (HOG) function uarta group uart1_rx_pr3

Live device-tree pad config (dtc -I fs -O dts /proc/device-tree):

hdr40-pin8 {                       hdr40-pin10 {
    nvidia,tristate = <0x00>;          nvidia,tristate = <0x01>;
    nvidia,function = "uarta";         nvidia,function = "uarta";
    nvidia,enable-input = <0x00>;      nvidia,enable-input = <0x01>;
    nvidia,pins = "uart1_tx_pr2";      nvidia,pins = "uart1_rx_pr3";
    nvidia,gpio-mode = <0x00>;         nvidia,gpio-mode = <0x00>;
};                                 };

TX: drive enabled, input disabled. RX: input enabled, output tristated. Both function uarta. This is correct.

serial@3100000 node (live, post DMA-removal):

serial@3100000 {
    iommus = <0x04 0x04>;
    compatible = "nvidia,tegra194-hsuart";
    status = "okay";
    reg = <0x00 0x3100000 0x00 0x10000>;
    ...
};

Symptom / measurements

Loopback test: physical jumper across pins 8↔10 (continuity verified with a meter). Writing to /dev/ttyTHS1 and reading back returns nothing at 9600 and 57600:

import serial, time
s = serial.Serial("/dev/ttyTHS1", 57600, timeout=1)
s.reset_input_buffer()
s.write(b"PING"); s.flush(); time.sleep(0.2)
print(repr(s.read(4)))   # -> b''

Scope/meter on the TX pad (pin 8): while continuously streaming 0x55, pin 8 reads ~0.3 V (and pin 10, jumpered to it, the same). A live UART TX should idle at ~3.3 V and average ~1.5 V while streaming 0x55. The pad appears to be floating / not driven, despite tristate=0 and function uarta.
The exact same external device + a CP2102 USB-TTL adapter works perfectly, so the device and my wiring are known-good.

What I’ve ruled out

❌ Wrong pin / miscount — pin 1 = 3.3 V, pin 2 = 5 V confirmed; jumper continuity on 8↔10 confirmed.
❌ Pinmux not applied — pinmux-pins shows function uarta (HOG), GPIO UNCLAIMED.
❌ Port held by getty/another process — nvgetty inactive, no holders of /dev/ttyTHS1.
❌ DMA fault (the 6.2.2 issue) — forced PIO mode, dmesg clean, no SMMU faults; no change.
❌ gpio-mode=1 — set to 0; no change.
❌ Permissions — user in dialout, port opens fine.

Questions

Is UART1 / ttyTHS1 on the 40-pin header (pins 8/10) functional on R39.2 / JetPack 7 for the Orin Nano Super devkit (p3768-0000 + p3767-0005)? Has it been tested on this release?
With function uarta, tristate=0, gpio-mode=0, and the HOG applied, why would the TX pad (PR.02) not drive? Is there an additional pad/prod setting (drive strength, pull, schmitt, or an MB1/prod-settings pinmux entry) that jetson-io’s hdr40 overlay does not set on R39?
Is jetson-io emitting nvidia,gpio-mode = <0x01> for a UART function a known bug on R39?
Is the correct flashed pinmux (from the Orin Nano pinmux spreadsheet / MB1 BCT) required instead of a runtime overlay for UART1 to actually drive the pad on this release? If so, what is the recommended procedure on R39?

Happy to provide full dmesg, the generated .dtbo, or any register dumps. Thanks!

carolyuu · June 14, 2026, 8:56am

— 🤖 This is an automated AI response. I’m here to help, but please verify important details! —

I could not find clear support for that in the provided Jetson Orin Nano documentation.

However, based on the information provided in the context, it seems that you have tried various steps to troubleshoot the issue with the UART1 on the 40-pin header, including enabling the UART1 through jetson-io, applying the known JetPack 6.2.2 DMA workaround, and checking the pinmux register state.

The Community Solutions provided do not directly address the issue with the TX pad not driving on the 40-pin header. However, they do provide information on how to enable UART1 on the 40-pin header, how to configure the pinmux settings, and how to troubleshoot UART issues on the Jetson Orin Nano.

To further troubleshoot the issue, you may want to try checking the device tree configuration, verifying that the UART1 is properly configured and enabled, and ensuring that there are no conflicts with other devices or pins on the 40-pin header. Additionally, you may want to try using a different UART or serial console to see if the issue is specific to the UART1 on the 40-pin header.

It is also recommended to check the NVIDIA Developer Forums and the Jetson Orin Nano documentation for any updates or known issues related to the UART1 on the 40-pin header.

Please note that the information provided is based on the context and may not be comprehensive or up-to-date. For further assistance, it is recommended to consult the official NVIDIA documentation and support resources.

— We support team will also look into your issue to have further suggestions soon. please stay tuned. —

DaneLLL · June 15, 2026, 9:19am

Hi,
We have the steps for loopback test in
Making sure you're not a bot!

Do you mean the steps work on Orin Nano developer kit with Jetpack 6.2.2 r36.5, and fails on Jetpack 7.2 r39.2?

consultingfutures · June 15, 2026, 11:10pm

Confirmed via your eLinux link that I’m on the documented ttyTHS1/pins 8/10; flow control is off; the TX pad measures 0.3 V and RX receives 0x00 (break), so the controller isn’t driving TX despite a clean probe. Is this functional on R39.2, or is a flashed MB1/prod pinmux required?

mechmentz · June 17, 2026, 7:07pm

I can reproduce what appears to be the same issue on an Orin Nano Super Dev Kit running JetPack 7 / L4T 39.2.0.

Board identification:

cat /proc/device-tree/model
NVIDIA Jetson Orin Nano Engineering Reference Developer Kit Super

tr '\0' '\n' < /proc/device-tree/compatible

nvidia,p3768-0000+p3767-0005-super
nvidia,p3767-0005
nvidia,tegra234

Installed packages:

nvidia-l4t-core        39.2.0
nvidia-l4t-kernel      6.8.12-tegra-39.2.0
nvidia-l4t-jetson-io   39.2.0

Observed behavior:

UART device /dev/ttyTHS1 is present.
RX path appears functional.
TX path on the 40-pin header (pins 8/10) appears non-functional.

Testing performed:

Connected an ArduPilot Cube Orange+ flight controller to the 40-pin UART.

Wiring:

Orin pin 8  -> Cube RX
Orin pin 10 <- Cube TX
Orin pin 6  -> GND

MAVLink telemetry from the Cube is received correctly on /dev/ttyTHS1.

Examples:

Heartbeats received
GPS data received
Vehicle status received

However, commands sent from the Orin do not appear to reach the Cube.

Examples:

MAVLink parameter requests fail
QGroundControl cannot download parameters over the UART link
MAVProxy param fetch never receives responses

The exact same Cube works immediately when connected by USB (/dev/ttyACM0).

With USB:

QGroundControl downloads all parameters instantly
MAVProxy param fetch succeeds
Full bidirectional MAVLink communication works

Loopback test on the 40-pin UART fails.

Pins 8 and 10 were shorted together and tested using both /dev/ttyTHS1 and /dev/ttyTHS2.

Example:

import serial, time
s = serial.Serial('/dev/ttyTHS1', 115200, timeout=1)
s.write(b'test\n')
s.flush()
time.sleep(0.2)
print(s.read(100))

Expected:

b'test\n'

Actual:

b''

Results were the same for:

ttyTHS1 @ 115200
ttyTHS1 @ 921600
ttyTHS2 @ 115200
ttyTHS2 @ 921600

Jetson-IO appears broken for this board variant.

Commands such as:

sudo /opt/nvidia/jetson-io/config-by-function.py -l all

and

sudo /opt/nvidia/jetson-io/config-by-pin.py -p 8

fail with:

RuntimeError: No DTB found for NVIDIA Jetson Orin Nano Engineering Reference Developer Kit Super!

This suggests Jetson-IO does not recognize the p3768-0000+p3767-0005-super platform even though the matching DTB files are present under /boot.

Given that:

RX works
USB MAVLink works
Loopback fails
Jetson-IO does not support the Super board ID

it appears the issue may be related to UART pinmux / header configuration / DTB support for the Orin Nano Super on L4T 39.2.

Topic		Replies	Views
Enable UART1 Jetson Orin Nano jetson	1	234	August 7, 2025
Enable and Use UART0 (THS0) on Jetson Orin Nano Jetson Orin Nano uart	9	1129	September 23, 2025
Orin Nano Jetpack 6.0 UART1 issue Jetson Orin NX uart	19	1180	July 26, 2024
UART2 (serial@3110000 / ttyTHS2) TX pad does not drive on AGX Orin custom carrier R39.2 / JetPack 7 flashed MB1 BCT pinmux is correct Jetson AGX Orin jetson	2	26	June 16, 2026
Jetson Orin NX (P3767-0004) JP6.1 – UART1 (serial@3100000 / ttyTHS1) not receiving data, PR2/PR3 remain GPIO (pinmux anomaly) Jetson Orin NX gpio , uart	4	97	March 5, 2026
Jetson Orin Nano UART for comms with external MCU Jetson Orin Nano uart	10	266	September 10, 2025
After update to R36.5, the gpio is fixed but uart in ttyTHS1 is not working in jetson orin nano baord Jetson Orin Nano kernel , jetson , jetson-orin	7	151	March 19, 2026
UART1: CTS RTS: flow control is not the same as UART0 Jetson Orin Nano uart	17	1562	April 17, 2024
Trying to use UART2, but /dev/ttyTHS1 doesn't exist Jetson Orin Nano uart	7	2438	August 8, 2023
How to generate 'ttyTHS1' of UART0? Jetson Orin Nano uart	16	212	January 2, 2026