UART2 (serial@3110000 / ttyTHS2) TX pad does not drive on AGX Orin custom carrier R39.2 / JetPack 7 flashed MB1 BCT pinmux is correct

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

Title: UART2 (serial@3110000 / ttyTHS2) TX pad not driving on AGX Orin p3701, R39.2 JetPack 7

Body:

Custom AGX Orin carrier (p3701-0000) on L4T R39.2 / JetPack 7, kernel 6.8.12-1021-tegra. UART2 (serial@3110000, ttyTHS2) won’t transmit. Controller probes fine, pinmux reads uartb everywhere, but the TX pad never drives.

Same symptom as this Orin Nano R39.2 thread:

Difference: I also checked the flashed MB1 BCT pinmux and it’s correct too, so this is below the pinmux layer.

Symptom: connector loopback (TX-RX, continuity checked) returns nothing at any baud. On a scope the TX pad stays flat while streaming, never toggles. Same device works on a USB-TTL adapter, so wiring is fine.

Controller probes:

3110000.serial: ttyTHS2 at MMIO 0x3110000 (irq = 134, base_baud = 0) is a TEGRA_UART

Runtime pinmux:

pin 118 (UART2_TX_PX4): (HOG) function uartb group uart2_tx_px4
pin 119 (UART2_RX_PX5): (HOG) function uartb group uart2_rx_px5

Base DT: serial@3110000 status okay, compatible nvidia,tegra194-hsuart, no pinctrl conflict, not a console.
Flashed BCT (tegra234-mb1-bct-pinmux-p3701-0000.dtsi): uart2_tx_px4 = uartb, tristate disabled, pull none, lpdr disabled. Correct.

Ruled out: wrong pin, pinmux not applied, BCT wrong, flow control, getty, permissions.

Questions:

  1. Is UART2 / ttyTHS2 working on R39.2 for p3701? Has TX been tested on this release?
  2. Pad is correct at both runtime pinmux and flashed BCT, so what else stops the TX pad driving? Any prod/pad setting on R39.2 the spreadsheet doesn’t generate?
  3. Same root cause as the Nano thread? Fix or patch?
  4. Does serial-tegra.c complete hardware init for this pad on R39.2?

Happy to share full dmesg, live DT dump, or register reads.

2

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

Based on the provided context, I found a similar issue reported in the community solutions.

The issue seems to be related to the UART2 (serial@3110000 / ttyTHS2) TX pad not driving on the AGX Orin custom carrier.

A similar issue was reported on the Jetson Orin Nano Developer Kit (Super) with L4T R39.2 / JetPack 7, where the 40-pin header UART (UART1 / /dev/ttyTHS1, pins 8/10) was not transmitting or receiving.

The solution provided in the community solutions was to check the flashed MB1 BCT pinmux and ensure it is correct. In your case, you have already checked the flashed MB1 BCT pinmux and it is correct.

Another possible solution is to check the device tree configuration for UART2. Ensure that the serial@3110000 node is enabled and the pinctrl settings are correct.

You can try to modify the device tree configuration to enable UART2 and see if it resolves the issue.

Additionally, you can try to check the kernel logs and dmesg output to see if there are any error messages related to UART2.

It is also recommended to check the pinmux spreadsheet and ensure that the UART2 pins are correctly configured.

If none of the above solutions work, you may want to try to use a different UART port or seek further assistance from the NVIDIA support team.

Here is a code snippet that may help to enable UART2:

&serial@3110000 {
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&uart2_tx_px4 &uart2_rx_px5>;
};

Please note that this is just a suggestion and may not be the exact solution to your problem. You may need to modify the device tree configuration further to suit your specific requirements.

Also, please ensure that you have the correct kernel version and device tree configuration for your Jetson AGX Orin custom carrier.

I hope this helps to resolve your issue. If you have any further questions or concerns, please feel free to ask.

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

4

Thanks. The bot’s suggestions are all things I already confirmed in the original post: serial@3110000 is status okay, the runtime pinmux reads uartb on both pins, and the flashed MB1 BCT is correct. The pad is configured correctly at every layer and still doesn’t drive on a scope.

So this isn’t a config error. Could a human engineer confirm whether UART2 TX is verified working on R39.2 for p3701, and whether this is the same regression as the linked Orin Nano thread?

6

Hi guillermo.karsz,

Are you using the devkit or custom board for AGX Orin?
Is the issue specific to r39.2? (i.e. Was it working with R36.x before?)

It seems you have confirmed the pinmux configuration correct in your case.
Please share the full device tree and dmesg for further check.

7

Hi, thanks for looking into this.

Board: Custom AGX Orin carrier (Tegra234 / p3701-0004 module). I don’t currently have a devkit to cross-check, but I can point to a closely related report [the Orin Nano devkit ttyTHS1 thread] shows the same “TX pad does not drive” symptom on a stock devkit on R39.2, which suggests this may not be carrier-specific.

R36 vs R39.2: I have not yet tested this board on R36.x, so I can’t yet confirm it’s an R39.2 regression.

Attached: full device tree (dtc decompile of the running base DTB) and full dmesg from boot.

running.dts.txt (359.6 KB)

dmesg.txt (128.6 KB)

8

Could you try if it would work with DMA mode by adding the following lines in device tree?

		serial@3110000 {
			resets = <0x03 0x65>;
+			iommus = <0x04 0x04>;
+			dmas = <0xee 0x09 0xee 0x09>;
+			dma-names = "rx", "tx";
			interrupts = <0x00 0x71 0x04>;
			clocks = <0x03 0x9c>;
			compatible = "nvidia,tegra194-hsuart";
			status = "okay";
			reg = <0x00 0x3110000 0x00 0x10000>;
			reset-names = "serial";
		};

Please simply verify it in loopback test before connecting to custom serial device.

9

I have verified UART1(serial@3100000) working with the loopback test on AGX Orin devkit with R39.2 as following:

root@Jetson:/home/nvidia# stty -F /dev/ttyTHS1 115200 raw -echo
root@Jetson:/home/nvidia# cat /dev/ttyTHS1 &
[1] 5962
root@Jetson:/home/nvidia# echo "test12345" > /dev/ttyTHS1
root@Jetson:/home/nvidia# test12345
10

Thanks. Before trying DMA, I want to flag that I think this thread was on the wrong UART.

Per NVIDIA’s Pin and Function Names Guide (DA-11060, Table 7), our carrier net “UART2_TX” (C58) maps to SoC GP41_UART5_TXD - i.e. silicon UART5 = UART-E = serial@3140000 / ttyS0, not serial@3110000. The CVM net names invert UART2 ↔ UART5 vs the silicon pads.

After configuring pinmux (uart5_tx_py5/rx_py6/rts_py7/cts_pz0, function “uarte”) and enabling serial@3140000, on R39.2/JP7 we see:

  • pinmux-pins: all four pads “function uarte”
  • ttyS0 → 3140000.serial
  • clk_summary: uarte enabled, 68 MHz
  • /proc/tty/driver/serial: tx: counter increments by millions when writing to /dev/ttyS0 - so the controller is actively transmitting.

So the SoC/UART side looks correct. The DMA snippet targets serial@3110000, a different controller not wired to our transceiver, so it wouldn’t apply.

Where it breaks is the carrier RS-232 transceiver (XR32220): with a valid RS-232 signal arriving (R1IN = −4.6V) and STATUS high, the charge pump rails read V+ ≈ 2.8V and V− ≈ 0V (should be ±5V) so the transceiver isn’t generating its supplies. That looks like a carrier hardware issue, not UART/pinmux/DMA.

Questions:

  1. Can you confirm the carrier UART2 = silicon UART5 = serial@3140000 mapping is expected on AGX Orin?
  2. Given the tx counter increments, do you agree the controller side is functioning?
11

Yes, you can refer to Jetson/L4T/peripheral/ - eLinux.org for the UART mapping on AGX Orin.

Could you verify if there’s the issue for serial@3100000 or the issue is specific to serial@3140000 or serial@3110000?
I can only verify serial@3100000 as this UART interface is available from 40-pins expansion header on the devkit. It could help to ensure the serial functionality works as expected.