USB latency with FTDI 601

Hello,

I am working on the Jetson AGX Orin DevKit 64GB with JetPack 6.2 (R36 rev4.3) installed, using SDKManager.
I also changed the pinmux to set some 40pin-header GPIO to output and reflash the Jetson with > sudo ./flash.sh jetson-agx-orin-devkit internal command.

For my project, I have an FPGA that pushes 100KB of data into the FTDI601 FIFO each millisecond. The chip is connected to the Jetson through USB and is well detected as a Superspeed USB Device in dmesg. To initiate bulk transfers, I use FTDI drivers that wrap around libusb.

Retrieving data within a millisecond is a critical constraint in my case.

When I try 100 transfers without any applications running and with no other USB devices connected:

  • On any USB-A port: Nominal latency is unstable (around 0.6 ± 0.3ms) and there are some spikes up to a maximum of 4ms.
  • On the USB-C port: Similar behavior, but nominal latency is around 0.3ms.

I tried the same code on my PC (x86) and my Raspberry Pi 5 (aarch64):

  • On any USB-A 3.0 port: Nominal latency is very stable (0.25ms ± 0.001ms) and there are no spikes.

I tried changing my process priority, installing PREEMPT_RT, and setting the power mode to MAXN, but nothing changed.

Are there any specific configurations to apply in Tegra that I might have missed ? Or is this a hardware limitation ?

Thank you.

Hi,

If you are designing a custom base board, then it means some adaptation configurations are needed.
Otherwise, your board may not work fine.

For Orin AGX series, you could refer to below document
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html?highlight=universal%20serial%20bus#jetson-agx-orin-platform-adaptation-and-bring-up
(please be aware that above link is for rel-36.3/jetpack6.0)

This document includes below configuration

  1. pinmux change & GPIO configuration
  2. EEPROM change as most custom boards do not have an EEPROM on it.
  3. Kernel porting
  4. PCIe configuration
  5. USB configuration
  6. MGBE configuration
  7. RGMII configuration

Thanks!

Hello,

I don’t design custom board, I use the default DevKit.
The behaviour with latency spikes was the same after the default installation through SDK manager (before the pinmux reflash).

Thank you.

You may need to share a simplified method that can reproduce similar error on devkit first.

Also share the full error log when issue happened.

Hello,

I need to simulate a stream of data from an ADC over USB in bulk transfer mode. This requires external hardware, and I cannot reproduce it without the FTDI60 chip. I use the same code, drivers, and FTDI chip for tests with the RPI5 and the devkit.

I use the FTDI API to send a read request (FT_ReadPipeAsync()) to the chip and receive the 100KB of data generated by the FPGA every millisecond. To measure the transfer time, I have a flag in the FPGA that rises when all 100KB of data are pushed into the FTDI FIFO.

For 100 transfers :


For 1000 transfers :

I repeated this test 10 times and always got the same result: spikes on the first transfers on the Jetson, but not on the Raspberry Pi 5. I would like to understand why.

I don’t have any other logs; I can only observe the latency fluctuations between each request.

It seems like the USB on the Jetson has a “sleeping mode” or some other default configuration.

Thank you.

Hello,

[Up] Do you have any ideas or workarounds for this problem ?
Maybe it is related to a low power mode on USB devices, which is enabled by default with L4T ?

Thanks.

Is that thing a usb3 or usb2 device when issue happened?

It’s usb3.

Hi,

We can try to disable USB U1/U2/U3 first.

U1/U2

To enable or disable U1/U2 on a specific USB port, follow these steps:

  • Identify the USB Port:
    First, you need to locate the USB port you want to work on. Navigate to the relevant directory:
    You should see output similar to the following:
ubuntu@jetson:/sys/bus/usb/devices/2-0:1.0$ ls
authorized         bInterfaceSubClass of_node              usb2-port1
bAlternateSetting  bNumEndpoints      power                usb2-port2
bInterfaceClass    driver             subsystem            usb2-port3
bInterfaceNumber   ep_81              supports_autosuspend usb2-port4
bInterfaceProtocol modalias           uevent
  • Check U1/U2 Enablement:
    To check whether U1/U2 is enabled on a specific port, read the usb3_lpm_permit file:
    If U1/U2 is enabled, you’ll see:
ubuntu@jetson:/sys/bus/usb/devices/2-0:1.0/usb2-port1$ cat usb3_lpm_permit
u1_u2
  • Enable/Disable U1/U2:
    To enable U1/U2, echo the appropriate value (“u1”, “u2”, “u1_u2”) into the usb3_lpm_permit file. To disable both U1 and U2, echo “0”:

U3/L2
To enable or disable U3 for USB devices:

  • Identify the USB Device Path:
    • Locate the USB device path for which you want to control U3/L2.
  • Check U3 Enablement:
    • Read the power/control file to determine if U3 is enabled:
      If U3 is enabled, the output will be:
root@jetson:/sys/bus/usb/devices/1-4/power# cat control
auto
  • Enable/Disable U3:
    To enable U3, echo “auto” to the power/control file. To disable U3, echo “on”.

Hello,

I tried to disable all USB low power modes:

dmesg output after plugging in the FTDI chip: “USB 2-1.3 new SuperSpeed USB device number 4 using tegra-xusb”

Commands executed:
    echo 0 > /sys/devices/platform/bus@0/3610000.usb/usb2/2-1:1.0/2-1-port3/usb3_lpm_permit
    echo on > /sys/bus/usb/devices/usb2/power/control
    echo on > /sys/bus/usb/devices/2-1.3/power/control
    echo on > /sys/bus/usb/devices/2-1.3/port/power/control

After these updates, I still observe spikes. I also tried updating all usb3_lpm_permit entries found in the /sys/ directory and setting the “autosuspend” parameter to 0 (default is 2000ms), but nothing changed.

I conducted new tests with two FTDI601 chips that request 100kB of data every millisecond in separate threads. I observed significant performance differences when plugging or unplugging the UFP port to connect to the Jetson via SSH from my host.


I still don’t understand why the Raspberry Pi 5 and my PC have better performance for these transfers.
Is it related to hardware or software configurations ?

Thank you.

Then it has nothing to do with usb low power mode. Again, back to what I told in the beginning, unless you provide a easy setup on NV devkit, it is not possible we can check this further.

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