UART1 (GPIO Header Pins 8/10 - /dev/ttyTHS1) Receiving Corrupted Data on JetPack 6.2.2 (Jetson Orin NX 16GB + Waveshare Base Board)

Hi everyone,

I’m facing an issue with UART1 on my Jetson setup and would appreciate any guidance.

Hardware

  • Jetson Orin NX 16GB
  • Waveshare Orin Nano/NX Base Board (40-pin GPIO header)
  • JetPack 6.2.2
  • Linux for Tegra (default kernel from JP 6.2.2)

UART Configuration

I’m using:

  • GPIO Pin 8 → UARTA TX
  • GPIO Pin 10 → UARTA RX
  • Device: /dev/ttyTHS1

The baud rate is configured correctly on both the sender and the Jetson.

Problem

Although UARTA is enabled, the received data on /dev/ttyTHS1 is corrupted or incomplete.

Symptoms:

  • Only a few bytes are received correctly.
  • Most packets are corrupted or missing.
  • Data appears as random/garbled characters.
  • Packet loss is observed.

I have verified that:

  • Baud rate matches on both devices.
  • TX/RX wiring is correct.
  • GND is shared.
  • The sender is working correctly (verified with another receiver).
  • The same sender works with another Jetson board.

What I Have Checked

  • UARTA is enabled using the Jetson Expansion Header Tool.
  • Pins 8 and 10 are configured for UARTA.
  • /dev/ttyTHS1 is present.
  • Serial console is not using /dev/ttyTHS1.
  • Flow control is disabled.
  • Multiple baud rates were tested.

Difference Between Working and Non-working Boards

Both systems use JetPack 6.2.2, but I noticed a difference in the Jetson Expansion Header Tool.

On the working Jetson, the pin configuration only shows the peripheral selection.

On the non-working Jetson, there are now three selectable options for these pins:


[*] unused
[ ] gpio
[*] uarta (8,10)

For UART CTS/RTS:


[*] unused
[ ] gpio
[ ] uarta-cts/rts (11,36)

The UART pins are configured as uarta, but UART communication is still corrupted.

Observation

This issue started after recent kernel/GPIO changes. I suspect there may have been changes to pinmux or GPIO configuration compared to earlier JetPack 6.2.2 images.

Has anyone observed similar behavior after updating the kernel or using newer JetPack 6.2.2 images?

Questions

  1. Has the pinmux configuration for UARTA changed in recent JetPack 6.2.2 releases?
  2. Is there any additional configuration required besides selecting UARTA in the Expansion Header Tool?
  3. Could this be related to recent GPIO/pinmux kernel changes?
  4. Are there any known issues with /dev/ttyTHS1 on JetPack 6.2.2?
  5. Is there a way to verify that pins 8 and 10 are actually configured as UART at runtime?

Any suggestions would be greatly appreciated.

Thank you!

Hi rohit.shah,

Have you confirmed that they are both Jeptack 6.2.2(r36.5)?
You can check the result of cat /etc/nv_tegra_reelease on both boards.

Please check if the following thread helps for your case.
Solved: UART/Serial Port not working after upgradint to Jetpack 6.2.2 (Orin Nano/NX) - #7 by KevinFFF

Yes, JetPack 6.2.2 (r36.5).

I have already implemented the changes mentioned in the thread by removing the DMA configuration and DMA names from the UART device tree configuration. After this modification, the issue has been partially resolved.

The UART receiving functionality is now working correctly, but the transmission side is still not working. The serial port is able to receive incoming data, but it is not transmitting any data back through the UART interface.

I have verified the configuration and the issue appears to be limited to UART TX operation. Could you please advise if there are any additional changes required for the TX path or any specific UART/DMA-related settings that need to be checked in JetPack 6.2.2 (r36.5)?

I will also verify the /etc/nv_tegra_release output on both boards and share the results.
R36 (release), REVISION: 5.0, GCID: 43688277, BOARD: generic, EABI: aarch64, DATE: Fri Jan 16 03:50:45 UTC 2026

KERNEL_VARIANT: oot

TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

Please add iommus = <&smmu_niso0 TEGRA234_SID_GPCDMA>; for serial@3100000 in device tree.