Extremely poor USB 3 performance on the Jetson AGX Orin 64 GB Dev Kit with FTDI FT601

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

Continuing the discussion from USB latency with FTDI 601:

I have a similar setup to USB latency with FTDI 601 , except for the GPIO use case. In my case, I simply configure the FTDI FT601 device to send a fixed size of data at regular intervals. However, the dev kit is not able to deliver all the data and the data rate I measure is far lower than what I expect. For instance when I set up a 13 MB transfer every second, I only receive 3.3 MB. I have tried the following to no avail:

  • both USB A and C ports,
  • changing the power mode,
  • disabling the USB low power modes,
  • reflashing the dev kit to R36.4.4, and R36.3 (the same version as a Jetson AGX Orin Nano that works perfectly).

Surprisingly the exact same setup works perfectly on the Jetson AGX Orin Nano. This dev kit is able to keep up with the data rate and deliver virtually all the data I request, even with other devices (keyboard, mouse) plugged in to the other USB 3 ports.

I have spent the last 3 weeks trying to find the problem and solution but I have not been able to. I believe it may have something to do with the USB drivers or XHCI controller, or even the hardware itself? Other people seem to indicate it may be an issue of the system downgrading the speed of the ports to USB 2 during transfer for some strange reason?

Does anyone have any solution to this please?

4

I don’t have a way to reproduce this, but you should look at a tree view of “lsusb” and post the output here:
lsusb -tv

The bit rate is listed at the right side. If it is 5000M or faster, then it is running in USB3 mode; if 480M, then it is in USB2 mode. The reason for downgrade to USB2 could be a number of issues, but the first thing to ask is usually if this is a developer’s kit, or if it is a module using a third party carrier board? This latter is because device tree has to be edited for most third party carrier boards.

Also, you might try a loopback test. Is the USB end on the Jetson, or the other end, or is it some other configuration? Often you can just directly wire (from the non-USB side) the TX and RX together and have the serial UART send to itself (makes a good test). If needed, you could also wire the CTS to RTS. If CTS and RTS are available, and if you know how to enable that at both ends, then flow control could improve data integrity (but it wouldn’t speed it up, it’d just make it more reliable since buffers would never overflow).

6

Thanks for your response @linuxdev .

Here is the output of lsusb -tv:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 10000M
        ID 0bda:0420 Realtek Semiconductor Corp. 
        |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 5000M
            ID 0403:601f Future Technology Devices International, Ltd Myriad-RF LimeSDR-Mini
        |__ Port 2: Dev 3, If 1, Class=Vendor Specific Class, Driver=, 5000M
            ID 0403:601f Future Technology Devices International, Ltd Myriad-RF LimeSDR-Mini
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 3: Dev 2, If 0, Class=Wireless, Driver=rtk_btusb, 12M
        ID 13d3:3549 IMC Networks 
    |__ Port 3: Dev 2, If 1, Class=Wireless, Driver=rtk_btusb, 12M
        ID 13d3:3549 IMC Networks 
    |__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 0bda:5420 Realtek Semiconductor Corp. 
        |__ Port 3: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M
            ID 046d:c52b Logitech, Inc. Unifying Receiver
        |__ Port 3: Dev 4, If 2, Class=Human Interface Device, Driver=usbhid, 12M
            ID 046d:c52b Logitech, Inc. Unifying Receiver
        |__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
            ID 046d:c52b Logitech, Inc. Unifying Receiver
        |__ Port 4: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            ID 413c:2003 Dell Computer Corp. Keyboard SK-8115

It is the developer kit.

Both ends are USB. On the FTDI side it is micro-B type.

A loopback test on the Jetson would be introducing another variable into the equation - the write performance, but I will look into it.

7

I am assuming this is the device in question:

This device is operating at USB3.2 gen. 1 speeds so far as USB goes. I’m not familiar with a USB serial UART cable with no exposure to individual wires on one end. This does indicate that two devices are recognized on one cable when plugged in to that Linux system. Looks like this is software defined radio. All of this is only the USB side.

Is there any exposed pins for TX and RX anywhere? Do you have a URL so I can see the exact hardware and perhaps specs and manuals? This would be for any FTDI cable if it is a serial UART cable, and for the SDR hardware.

Also, does this exact tree view lsusb -tv show up with 5000M speed regardless of being R36.3 or R36.4.4? I don’t know if the tree view lsusb -tv you gave is for the failing case or the working case, but for now I’m assuming it is the failing case (which would mean USB itself is not the issue).

8

The output of lsusb -tv is from the failing case.

I don’t know why it is showing up as an SDR. It is actually a FIFO to USB Bridge. It also shows up as an SDR in the working case (the Orin Nano), but shows up as a FT601 32-bit FIFO IC on my PC.

Also, does this exact tree view lsusb -tv show up with 5000M speed regardless of being R36.3 or R36.4.4?

Pretty much, yes. I have not observed any significant difference in the lsusb -tv output between the releases.

9

If you boot up without having the FTDI connected, and then monitor “dmesg --follow”, what new log lines show up for (A) the working case, and (B) the failing case? I’m looking for differences and any mentions of drivers. USB has its own driver, but it is hot plug, and when the device announces what it is, then other drivers can take over. Mostly it seems the next question is “what are the other drivers and how do they differ”.

Also, did you have to install any driver? If so, were they using a different driver other than for being an ARM 64-bit driver?

It would be good to continue to keep the power mode maxed during any testing, and to keep the USB autosuspend off (even if we find a difference it would probably throw things off if one of those modes changed between tests).

10

Here is the output of dmesg –follow -T from the failing case when I connect the FTDI:

[Fri Oct 10 10:06:45 2025] usb 2-3.4: new SuperSpeed USB device number 3 using tegra-xusb

Here is the output on the working case:

[Fri Oct 10 10:45:42 2025] usb 2-1.3: new SuperSpeed USB device number 3 using tegra-xusb

Nothing else is printed when the FTDI is connected in both cases.

I installed the FTDI D3XX Linux drivers for ARM v8, and added the udev rule as follows:

cat /etc/udev/rules.d/51-ftd3xx.rules 
SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="601e", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="601f", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="602a", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="602b", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="602c", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="602d", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="602f", MODE="0666"

The power mode is set to MAXN, and USB autosuspend is turned off on the failing case. The working case did not need these changes, it just works.

One difference I have observed is that the 4-port USB 3.0 Hub on the failing case is a Realtek hub:

4-Port USB 3.0 Hub
Manufacturer: Generic
Speed: 10Gb/s (super+)
Bus:   2
Address:   2
Number of Ports: 4
USB Version:  3.20
Device Class: 09(hub  )
Device Subclass: 00
Device Protocol: 03
Maximum Default Endpoint Size: 9
Number of Configurations: 1
Vendor Id: 0bda
Product Id: 0420
Revision Number:  1.40

Config Number: 1
	Number of Interfaces: 1
	Attributes: e0
	MaxPower Needed:   0mA

	Interface Number: 0
		Name: hub
		Alternate Number: 0
		Class: 09(hub  ) 
		Sub Class: 00
		Protocol: 00
		Number of Endpoints: 1

			Endpoint Address: 81
			Direction: in
			Attribute: 19
			Type: Int.
			Max Packet Size: 2
			Interval: 16ms

while on the working case it is from VIA Labs:

USB3.1 Hub             
Manufacturer: VIA Labs, Inc.         
Speed: 10Gb/s (super+)
Bus:   2
Address:   2
Number of Ports: 4
USB Version:  3.20
Device Class: 09(hub  )
Device Subclass: 00
Device Protocol: 03
Maximum Default Endpoint Size: 9
Number of Configurations: 1
Vendor Id: 2109
Product Id: 0822
Revision Number:  8.b3

Config Number: 1
	Number of Interfaces: 1
	Attributes: e0
	MaxPower Needed:   0mA

	Interface Number: 0
		Name: hub
		Alternate Number: 0
		Class: 09(hub  ) 
		Sub Class: 00
		Protocol: 00
		Number of Endpoints: 1

			Endpoint Address: 81
			Direction: in
			Attribute: 19
			Type: Int.
			Max Packet Size: 2
			Interval: 16ms

Could it be a hub issue?

11

To start with, it doesn’t look like the USB itself (from plug-in event) is an issue. A udev rule could modify things to show the LimeSDR-Mini, but most likely (A) this won’t harm anyting, and (B) there is likely some sort of programming of that customization in the hardware itself (a udev rule could do this; however, if the ID does not change, and if the driver does not change, then probably this would not harm anything).

So far as the HUB goes, it could change things. I wouldn’t say it is a “smoking gun evidence”, but this is the most “different” part between them at the moment. Can you see if swapping the HUB from the working case to the Jetson? Both show as 10Gb/s, although technically the “USB 3.0” on the “bad” case (I’m not saying this is the cause of the bad case) would only be 5Gb/s (USB 3.0 is the original 5Gb/s standard, which is the same as USB3.1 generation 1; it isn’t until you get to USB3.1 gen. 2 that 10Gb/s is supported, but this is just a description issue and the software does not depend on this).

I would try:

  • Switch HUBs.
  • Try direct to a port without a HUB (not sure if this is practical unless you’re using a model with 2+ USB3 ports).

If this not change anything, then likely it isn’t the HUB.

12

Swapping the HUBs will be very risky for us at the moment because of the current stage of the project.

Anyway, like I mentioned in my original post, I have the same issue when I use the USB-C port, so l don’t think the HUB is the problem.

13

Where is power being drawn from for any USB device? Is power being provided by the device, and thus not consuming anything from the Jetson or the HUB? Is power being drawn from a powered HUB? Is power being drawn from the host of the device?

The theory is that in normal operation if device or devices consume a total power in excess of what USB2 can provide over a cable, then it must use USB3. This would seem unrelated to speed and other qualities (like data loss), but if there is a need to reduce to USB2 for data reasons, and yet the device is held as USB3 due to mandatory data rates, and if this is on the edge of limitations, then there could be some "squirrely"™ behavior which could account for requirements of resending data. A UART typically does not draw anywhere remotely close to enough power to cause such an issue, but if you are using an unpowered HUB, and if there are other devices involved, then it could matter (admittedly, it is a remote possibility). Do both working and non-working depend on the host to power it? Is power independent, including for other devices?

I’m getting more curious about a loopback test. In the failing hardware it would say a lot if you can verify loopback working or failing. RF can be a rather complicated topic, and perfectly working hardware in a given combination can cause a loss of data quality even when the individual pieces work. Loopback would help determine if one side is working or failing. Then we know the other side is failing if the original worked, or else that a combination of conditions of both sides working is an issue. However, if loopback fails on something, then you have “smoking gun” evidence of where the issue is.

Just a minor question, why was the port permission in need of change via udev rule? What owner and group would the device have in the failing case if there were no udev rule? Assuming only mode is changed, then using “ls -l” on the device would still tell the owner and group (which the rule would not have changed). I’m wondering if it is part of the environment causing the issue (yes, it is reaching a bit, but we’re kind of running out of things which are easy to test since NVIDIA would have to be able to reproduce this and they won’t have the same hardware).

14

The device is self-powered, so it theoretically should not be consuming anything from the Jetson.

No. The FTDI device uses external power and its USB port is self-powered.

About the loopback test, I am not sure how to do that on either side. The FTDI side gets its data from an FPGA FIFO, so I don’t really have much control on that side. On the Jetson side, can I just plug a USB cable from the USB-C device mode port to any of the other ports and write some code to stream bytes from the device only port? Or I just tie the TX and RX lines on a normal USB cable and plug it into any USB port? Pardon my ignorance, this is not something I am familiar with.

The owner and group of the device without the udev rule is root:root. So the udev rule allows my FTDI application to access the device without root privileges.

Could the storage medium be the issue? The working case (Orin Nano) uses an SSD while the failing case still uses the supplied eMMC storage? Perhaps the USB system on the failing case is not writing to the usbfs fast enough?

15

Let me back up and ask more about that board and how it is connected. It might get repetitive.

  • Is it correct that this board has a USB cable and it is connected?
  • Are there header pins which are used for data?
    • If there are header pins for data, are these standard UARTs with a setting for speed, bits, stop bits, etc.? Those are the settings for standard UARTs. I am interested in knowing if these are truly standard FTDI UARTs, or if it is something else.
    • You mentioned GPIO. If Jetson GPIO is involved, is this also connected to the Jetson, or are those headers going to some other hardware?
  • Does the FPGA side boot before the Jetson, after the Jetson, or at the same time? Does data automatically start from boot, or do you have to start this? There are often timing issues for PCIe-based FPGAs which are booted too late, but assuming the FPGA is not on the PCIe slot, then you can ignore this. However, it would be nice to know exactly what the FPGA is connected to and if the tests are able to run manually.

It is unusual to see a “root/root” serial device, at least from FTDI or other serial UARTs on USB. What driver was used, and how was it added? If it is an FTDI UART driver then it should “just work”, but if it is something else, then it might be handled differently.

Also, do you have an oscilloscope handy such that you could send a data test pattern continuously (even without the FPGA and looking only at the Jetson) and monitor the output? This would depend on data pins being exposed/used (other than USB).

We know this is a FIFO-to-USB3 device, but we don’t know if it is truly a UART. This one is rather important: Does the Jetson software utilize the device via a file in “/dev”, and is that file named something like “/dev/ttyUSB#”? If one of those files are used (I’ll pretend it is “/dev/USB0”, but adjust), then what do you see from:
sudo stty -F /dev/ttyUSB0

If header pins are used for data, does it use a single transmit wire and a single receive wire for data on any given “channel”? If it does, then it can probably be treated like a UART and loopback tested simply by connecting those two wires together and sending and receiving at the same time on the device special file. If this has data loss then the issue is at the Jetson side. If no loss while doing that, then it is another issue, e.g., being under load and losing data, or timing issues.

16

It has a Micro USB Type B port which is used to connect to the Jetson through a standard Micro-B to Type A (or Type C) USB Cable.

My knowledge of the internal workings of the UMFT601X are quite limited so I will have to quote AI here:
——- AI Generated Reponse: —————-

Here’s how I’d explain it, based on the FT601/UMFT601X documentation and how FTDI’s FT60x series works:

TL;DR answer

  • There are header / connector pins on the UMFT601X (via its FMC/HSMC connectors) that carry data — these are not UART-level serial lines but parallel FIFO lines (i.e. a parallel bus) + control lines (RD, WR, OE, etc.).

  • The FT601 / UMFT601X does not implement a UART over USB; it implements a USB-to-FIFO (parallel bus) bridge.

  • Thus you don’t configure “baud rate, stop bits, parity, etc.”: you treat the interface as a high-speed parallel interface (FIFO) to/from the USB host, not as a conventional UART serial port.

More detailed explanation & evidence

What the FT601 / UMFT601X is

  • The FT601 is a SuperSpeed USB 3.0 to parallel FIFO bridge (32-bit wide) device. (FTDI)

  • The UMFT601X is a development/evaluation board module that exposes that FT601 as a device with an FMC (or HSMC in alternate variant) connector to connect to external hardware (e.g. FPGA). (FTDI)

  • On the UMFT601X, the FMC connector pins map directly to the FT601’s FIFO and control signals (data lines, clock, read/write strobes, etc.). (Manuals+)

So it is fundamentally a USB ↔ parallel-FIFO bridging device, not a USB ↔ UART converter.

What “header pins for data” means in this context

The “header pins for data” are the lines on the FMC (or HSMC) connector that carry:

  • DATA[i] lines (for i = 0…31 for a 32-bit interface) (Manuals+)

  • Control signals such as RD_N, WR_N, OE_N, SIWU_N (switch input wakeup), RESET_N, WAKEUP_N, and possibly GPIO lines. (Manuals+)

  • Clock or timing signals, e.g. a D_CLK line (FIFO bus clock) output from FT601 to synchronize reads/writes. (Manuals+)

Hence “header pins for data” is accurate, but in the sense of parallel bus lines, not serial lines like UART.

Are the data pins UARTs (with configurable baud, parity, etc.)?

No — these are not standard UART lines. Here’s why:

  1. No serial framing or protocol — The FT601 does not implement UART protocol (start/stop bits, parity, etc.). It expects bursts of parallel data over the FIFO interface.

  2. You don’t set baud rate, data bits, etc. — In its role as a USB-to-FIFO device, the configuration you do is in terms of FIFO depth, channel usage, burst sizes, etc., but not UART configurations.

  3. It is treated as a “vendor class” USB device with FIFO endpoints — it uses its own driver interface (FTDI’s D3XX driver) or library to manage transfers. (FTDI)

  4. Multiple parallel data channels (IN/OUT) — The FT601 supports up to 4 IN channels and 4 OUT channels for data to/from USB, utilizing its FIFO interface. (FTDI)

Thus, the “data header pins” are part of a custom parallel interface, not a UART interface.

Why FT601 uses parallel FIFO instead of UART

  • The target use case is high throughput (USB3 speeds) and bulk data transfer (e.g. imaging, data acquisition), which is far beyond what UARTs can provide in terms of bandwidth.

  • The FIFO interface is designed to allow efficient bursts, pipeline transfers, and parallel loading/unloading of data with minimal software overhead.

  • In effect, the device is aimed to be “transparent” at a higher level: you put data into the FIFO, and FT601 handles the USB transport, without needing to manage low-level serial framing.

What the “optional GPIOs” are

While the main data bus is a parallel FIFO, there are some optional/general-purpose I/O pins (GPIO_0, GPIO_1) and wake/reset lines exposed via the FMC connector. (Manuals+)
These are not full UART ports either — they are simple digital I/O or control lines.

In summary (restating key contrast)

  • Yes, the UMFT601X has “data header pins” via FMC that carry data and control signals

  • No, those are not UART-level serial lines — they are a parallel FIFO bus

  • You do not set UART parameters (baud, parity, stop bits) on them

  • The FT601 is a USB-FIFO bridge, not a USB-serial (UART) bridge

No I am not using GPIO whatsoever.

The Jetson boots before the FPGA and I start the data transfer manually (via software). The FPGA is virtually a separate device from the Jetson in this setup. The Jetson has no other “dealings” with the FPGA except this USB 3 connection used to receive data from the FPGA via the UMFT601X FTDI device. I setup the data transfer on the FPGA from a separate device via standard USB-to-Serial (UART) connection and an Ethernet connection.

It is not a serial UART. As I mentioned previously, I installed the D3XX Linux drivers for ARM v8.

The FPGA sends data and other necessary signals to the UMFT601A (FTDI evaluation board) via an FMC connector. I could go down rabbit hole of trying to supply test signals on that interface, but that is not necessary because I am fairly confident that is not where the problem is.

It is not a UART so the device does not show up as a /dev/ttyUSB#

The UMFT601X board does not expose the USB pins so a loopback test will not be trivial. But I still strongly believe that the problem is on the Jetson side. I just tried the same setup with my PC and a Raspberry PI 5 and they both work perfectly.

17

There is also the possibility that for some reason specific to the failing case, the FTDI’s D3XX driver is failing silently and falling back to sub-optimal USB transfer parameters. I am not aware of how to confirm this though since these are proprietary drivers.

18

Here is an image of some USB2 and USB3 connectors. Can I verify this is the “Micro-B” for USB3 in the lower right hand corner of the image?
https://upload.wikimedia.org/wikipedia/commons/8/82/USB_2.0_and_3.0_connectors.svg

A recap of an excerpt of one point before going in further, from the “lsusb -tv”:

|__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 5000M

Do look carefully at this:
Class=Vendor Specific Class, Driver=,

What this says is that there are a chain of drivers, and not just USB drivers; USB drivers are for the data pipe, and indeed that pipe can cause the issues you are working on. However, there is also the driver for the device, and not just the USB drivers. This is the “Vendor Specific Class”. So we are trying to confirm or eliminate the USB part of this, and we can look for obvious issues, but if we can’t, then we might also need to look at the vendor specific driver. Perhaps this driver is in the form of a module and might (if a module) show up in “lsmod”. Maybe (or maybe not) this is an issue of that driver in the particular kernel.

We do see that USB is operating at USB 3 speeds (USB3.1 gen. 1, 5000 Mb/s). I kind of wish I knew the source code of the vendor specific driver.

Later we see this in the verbose USB comparison of working and failing cases:

# Working:
USB3.1 Hub             
Manufacturer: VIA Labs, Inc.         
Speed: 10Gb/s (super+)

# Failing:
4-Port USB 3.0 Hub
Manufacturer: Generic
Speed: 10Gb/s (super+)

Both see the same USB information, but this is for the HUB, not the devices themselves (the HUB shows USB3.1 gen. 2 speeds of 10 Gb/s, with two devices at USB3.1 gen. 1 speed, 5 Gb/s; this is how it should be, USB so far is functioning correctly).

Just a note about vendor specific classes: There are a few “standardized” devices which USB always has drivers for, e.g, certain human interface devices (keyboards, mice). A vendor specific class implies the driver itself is something custom talking through USB. Those “standardized” device drivers, although they ship with USB drivers, are not technically part of USB itself. For example, although a keyboard is a standard device and USB has a driver for it, there is still a device driver which talks through the USB pipe, and this is just convenience that it is present since it is so widely used. Your vendor specific class can in fact be an ordinary FTDI driver (this is still vendor specific), but not show up as using the more common FTDI driver for the device simply because of customized information in the board itself; the driver could be nothing more than a udev rule renaming it such that the standard FTDI driver could then be used. The way this board works I’m thinking it is not just a renamed FTDI driver, but the vendor specific driver might contain that code in some hidden way. The reason I’m telling all of this is that we really need to know more about the vendor specific driver if we cannot find the fault in the USB driver (which is not the end device driver).

If the udev rules from earlier do nothing more than change file permissions, then we don’t have to worry about a simple rebranding, and this probably is not using the FTDI UART driver even if it has a lot in common with it.

The AI description is good, it tells me it isn’t the usual serial device driver IOCTL() calls for configuring. It also verifies the vendor specific class driver is not a rebranded FTDI UART driver. It also gives me an idea for loopback testing. If this doesn’t show anything, then it might be necessary to look at the source code of the D3XX driver. In this regard, do you see what is probably the driver for this device under either of these two commands (it’ll show more drivers than just this one, you’ll need to find yours) on the working and failing cases (if the config.gz feature is not on for the other system ignore this; not all Linux systems export config.gz)?

  • zcat /proc/config.gz | grep 'D3'
  • zcat /proc/config.gz | grep 'FTDI'

This file shows all driver symbols, and not just modules. Also, if this is a module, then you might find the driver module under “lsmod”. Let me know if you can identify (A) the symbol for the driver, or (B) the module name. Then, let me know where the driver came from such that I can maybe download it as source code, or at least the documentation if not the source code.

Regarding loopback, if you have some dummy data, and assuming this has more than one “channel”, is it possible to directly wire one channel to the other such that one sends to the other and you can send data from the Jetson and compare the output to what the other channel sees? If you can do this it removes behavior from any cabling beyond the USB cable, and might isolate by showing loopback also loses data, or that loopback does not and thus the issue is at the other end of the data source/sync.

Also, have you been able to look with a logic analyzer (not always available) to see if the data being sent is reaching the FTDI device? I’m assuming it probably is, but it is worth asking. Loopback itself removes the FPGA from the test. Behavior suggests that loopback will also fail the same way as the FPGA, but we don’t really know unless we can run loopback.

20

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