FPGA connected to tk1 can't be detected as usb3.0

I have a FPGA with FX3 SDK to collect signal samples and transfer data to tk1 through usb. And I have enabled the USB port as 3.0 in the L4T 21.3 release by editing usb_port_owner_info to 2 in /boot/extlinux.conf.

But when I connect the FPGA to tk1 and download the firmware into the FX3’s RAM, it’s detected as usb2. However, when I do the same thing on my laptop, it’s detected as usb3.0.

Can anyone figure out where the problem exists?

Thanks for your private or public comment/suggestion.

lsusb -vvv result
laptop:

Bus 002 Device 003: ID 04b4:00f1 Cypress Semiconductor Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00

tk1:

Bus 001 Device 028: ID 04b4:00f1 Cypress Semiconductor Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10

On the JTK1, what is the tree view lsusb (“lsusb -t”)? In the past there have been some issues USB3 being labeled as USB2, yet really running at USB3 speeds. First thing is to guarantee the root HUB associated with the device is USB3 (tree view works great for that).

Thanks for your reply, linuxdev.

lsusb -t result
When I connect the FPGA and download the firmware into the FX3’s RAM, then I execute “lsusb -t”, the device is USB3:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M
    |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M

But after a while, about few seconds, the device is missing(with many infos about no file for device 2-1:1.0):

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M
    |__ Port 1: Dev 0, If 0, Class=(Defined at Interface level), Driver=, M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M

And a few seconds later, it is running at USB2:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M
    |__ Port 3: Dev 7, If 0, Class=Vendor Specific Class, Driver=, 480M

So the first lsusb -t shows USB3 is set in both root HUB and the FPGA. It seems like the second lsusb can only result from an error where device query is not responding, or something drastic enough that speed cannot be determined. If speed was determined to result in failure, it may have caused backing off to USB2 speeds…the root HUB still indicates USB3 capability. It would be interesting to see what a USB3 protocol analyzer says, but those are rather expensive.

I’m wondering if the tail of dmesg might show something? I’d check what the final log is for dmesg, prior to ever connecting the FPGA, and then connect the FPGA and see what appends to dmesg logs as things progress.

Incidentally, I doubt power delivery would be an issue for this case, but running at higher speeds does demand more power (and quality power delivery). You may also want to try this with a powered USB3 HUB.

Thanks a lot!
I followed your advise and try the connection with a USB3 HUB and it worked.
But I’m confused about the reason. Is HUB can deliver more power to FPGA than direct connection? Or something else?

This is all speculation since actually knowing would require some very expensive equipment…

I doubt it is power delivery in any obvious way, it’s probably a combination of things. A powered HUB is required to be able to deliver more power than powering through the host computer. Although your device probably does not use enough power on average for it to seem to matter, there are times when a very short spike in power requirement could change the timing of a signal very slightly (and the faster the signal the more delicate those timings become…USB3 data speeds are very fast compared to USB2).

The other thing is that the HUB has a transceiver on each port, and transceivers may have different abilities to work under noisy conditions (including drive levels to the next device differing…the FPGA may have lower drive output versus the HUB and the HUB transceiver may better handle low/noisy drive input versus the Jetson). Combinations of transceivers and power delivery have a tendency to compound on each other.