Interference between NVMe and UART

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
1

When performing a self-test on a Jetson AGX Orin developer kit, I found that writing to the NVMe SSD may interfere with the UART signal.

Release

nvidia@ubuntu:~$ cat /etc/nv_tegra_release
# R36 (release), REVISION: 4.0, GCID: 37537400, BOARD: generic, EABI: aarch64, DATE: Fri Sep 13 04:36:44 UTC 2024
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

PIN

UART1_TX is directly connected with UART1_RX

Steps to Reproduce

First, install python3-periphery

nvidia@ubuntu:~$ sudo apt install python3-periphery

Next, execute the following python code to perform UART loopback test

from periphery import Serial
s = Serial("/dev/ttyTHS1", 115200)
data_len = 1 << 7
data = b"\xff" * data_len
while True:
    while s.read(data_len, 0.1):
        pass
    s.write(data)
    data_read = s.read(data_len, 1)
    if data != data_read:
        print(f"get {len(data_read)} bytes")
        print(data_read)
        break
    else:
        print("loopback ok")

Finally, write NVMe SSD with zeroes

nvidia@ubuntu:~$ sudo dd if=/dev/zero of=/dev/nvme0n1 bs=1G status=progress

The loopback test fails after writing to the NVMe SSD.

a
a807×605 55.9 KB

How to fix this?

3

Hi,
On Jetson platforms, we support using peripherals like CAN, SPI, I2C, UART… etc. for the user.
For CAN usage:
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/ControllerAreaNetworkCan.html
For the connection of peripheral on the devkit, please refer to expansion-headers guide and carrier board specification:
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/ConfiguringTheJetsonExpansionHeaders.html

For pin configuration, please refer to pinmux spreadsheet:
https://developer.nvidia.com/embedded/secure/jetson/agx_orin/jetson_agx_orin_pinmux_config_template.xlsm

By default, the configuration is used for the devkit. If you are using the custom carrier board, please configure it according to your custom board design.

There are also several examples which have been verified from us, please check
https://elinux.org/Jetson/L4T/peripheral/
Please share the full dmesg and device tree for us to check your status in detail.

Thanks!

4

Hi 5d867a92b9bdd01df324966db,

Do you mean UART1_TX to UART1_RX?

Could you run the following commands to disable getty service and verify again?

$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service
5

Do you mean UART1_TX to UART1_RX?

Yes

Could you run the following commands to disable getty service and verify again?

Same result.

6

Are you booting from internal eMMC and running dd command to write /dev/nvme0n1?

Have you tried using a scope to capture those 0xFF data when you are running dd command?

7

Just a thought, could this be due to UART interrupts not being serviced in time? Doing high bandwidth I/O such as NVMe read/write on R36.x results in a very high interrupt load on CPU#0.

See R36.3 Patch to re-enable GICv2m for PCIe MSI interrupts and restore I/O performance

8

We do not think there is any interference between NVMe and UART.
It’s just that the CPUs are busy which might cause delay while reading data from UART port and cause an overflow, an interference would actually cause garbage data.

You can try connecting RTS/CTS and then run the same test with HW Flow control enabled, this will rule out any interference with PCIe.

1 Like
10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.