I’ve had issues using FLIR Blackfly USB cameras over the last months, they have upon repeated connections, defaulted to USB 2.1 speeds when connected to the AGX’s USB C ports. I initially put this down to the camera and had been following it up with FLIR. However i have recently had the same issue on a different xavier with an SSD defaulting to USB 2.1 speeds and I want to know if there are any known bugs of this kind?
Some specifics:
The device in lsusb will come up as a 3.1 device (5000M etc.), but will cap out at known USB2.1 speeds. On the camera this is identified by an error about maximum framerate well below normally operating speeds. On the SSD this was confirmed by a simple large file move test.
Replugging the camera does not solve the issue.
Moving the camera to the other USBC port will sometimes resolve the issue, swapping between the two ports will eventually solve the issue.
Hi,
For Ttype-C port, there are J512 and J513 ports on Xavier devkit. Please check which port has the issue(or both ports), and confirm it is not enumerated as SuperSpeed in dmesg print. And share your release version( $ head -1 /etc/nv_tegra_release ) for reference.
Release: R32 (release), REVISION: 2.3, GCID: 17644089, BOARD: t186ref, EABI: aarch64, DATE: Tue Nov 5 21:48:17 UTC 2019
Both ports are problematic. If you need the dmesg/lsusb feed give me a couple days to try and replicate the issue. I posted this now without having access to it, to see if this issue was known.
Hi,
We have E-Con See3CAM CU135 USB camera in office. Tried to connect it to J512 or J513 with type-C to type-A adapter and don’t observe the issue. If you have other USB3 device such as pendrive, please give it a try. To check if the issue is specific to the USB cameras.
As I stated in the inital post, this has now been confirmed to happen with an ssd on a different xavier. As does this camera issue happen on different xavier.
The problem tends to reliably occur if the cameras are plugged in on startup, and/or the process that initiates the camera is a startup process (I.e. Systemd service).
Hello, I am having a similar issue. I have an IDS uEye camera, USB 3.0, that I plug into the USB-A port on a Jetson AGX Xavier. Sometimes it enumerates as a USB 2 device, which limits the operation. This is my release version:
R32 (release), REVISION: 1.0, GCID: 14531094, BOARD: t186ref, EABI: aarch64, DATE: Wed Mar 13 07:41:08 UTC 2019
The camera works fine when plugged into one of the two USB-C ports using a USB-C cable, and I’ve also verified that the USB-A cable I am using is good.
I’ve noticed that when the device enumerates as USB 2, it is associated with Bus 1, i.e., the USB 2.0 root hub, and when it enumerates as USB 3, it is associated with Bus 2.
Unfortunately the driver uses a systemd service, so that may be an issue. But is there a way to force enumeration on Bus 2/as a USB 3 device?
The PHY itself routes to either of two different controllers, depending on whether the device needs USB2 or USB3. This part is working as intended. The real question becomes one of why it picked USB2 instead of USB3.
Some devices cannot operate at USB3, and so it would always route to USB2. If signal quality is insufficient, then the device would automatically switch to USB2. Also, if sharing a HUB (any HUB chip, not necessarily an external HUB), then no device can operate any faster than what the HUB is operating at.
I’ll recommend that when the device is on the type-A port you provide “lsusb” output, once when working as USB3, and once when it falls back to USB2 speeds. The same would be needed with the tree view, “lsusb -t”. In addition, when you run “lsusb”, notice that there is an “ID”, and it follows the format of “1234:5678” (the actual value can be seen from plain “lsusb”, this is just an example). You will want to provide a verbose lsusb in both cases as well…once from reverting to USB2, and once when working correctly as USB3: sudo lsusb -d 1234:5678 -vvv 2>&1 | tee log_name.txt
(this will create a log of the output to "log_name.txt, and this can be attached to forums)
Note that forcing to USB3 when it has fallen back to USB2 would just remove the device from enumeration (the device would not run at USB3, it would simply be removed since falling back would fail). Falling back to USB2 is not a “choice” per se, it is a limitation of current “best ability”.
Hi, thank you for the reply. I collected the log files you requested, though while trying different things to get the camera to enumerate in the two modes, I think I narrowed down the problem. I believe the USB 3 pins in the USB A connector are not making good contact. Pushing the connector down causes the pins to separate and a USB 2 enumeration, whereas pulling up ensures good contact and USB 3 enumeration. It was only when I started doing this that I could get reliable enumerations one way or the other, and I cycled through the two possibilities ~10x to gain some confidence.
Incidentally, I am wondering if you know the answer to the following, so I’m attaching the log files anyway: The bottom of the USB 2 log (log480.txt) shows Device Status: 0x0000, whereas the bottom of the USB 3 log shows Device Status: 0x000C. Additionally, it also shows “U1 Enabled” and “U2 Enabled”. Do you know what accounts for these differences or what they could mean?log480.txt (3.7 KB) log5000.txt (3.8 KB)
Someone from NVIDIA would have to look at those particular codes. It does sound like your physical connector is indeed the issue, and it would match the reasons for all that has been going on.
@heglex
A thought, if we have a way to force the usb controller to reattempt a connection while its still plugged in, then we might find its attempting to connect while the usb3 pins haven’t made proper contact yet, but that once it’s properly plugged in it’s fine?
It appears to be a short fall in the software on the tx2, superspeed is seen if the device is plugged in one way, and low speed if the plug is turned upside down.
I have a ptn36043 on my board and have found a software module that would support it, but the software does not compile in the kernel. looks like 4.9.140 did not have any typec support originally, someone added some support and it seems to be missing the mux and some other level to call my software to change to superspeed if the cable is upside down.
Do you know anyone in nvidia that would offer explanation of the typec usb subsystem that is in r32.3.1?
I have not sufficiently studied USB-C to know for sure, but there is no doubt some sort of “detect” function possible for connector orientation. Someone from NVIDIA would have to answer about changes in USB-C behavior depending on which way the cable connects.
I don’t know if it will show anything or not, but if you monitor “dmesg --follow”, and then connect and disconnect using the two different connector orientations, does dmesg show the same logging, or does each orientation show a unique log message?
I’ve still been following it up, there seems to be an element of “angle of attack” to when you plug the usb in that can affect what the usb comes up as. If it’s an issue with the connector though there’s not much to be done, usb-c is actually a pretty flakey connector, see all the phones that need to be fixed after 6months. But it also could be the controller being overly eager on connection or some other software level issue.
Looking at later kernels, there appears to be alot of support code for typec that is not in the nvidia code. Is better typec support being worked on and will it allow users to use other typec usb chips.
If nvidia was using a newer kernel my problems would go away, so when will newer kernel support be available or planned, we would also have to coordinate with our camera vendor to get a new camera driver for the new kernel/release
you can download generic 4.19.xxx and look at tcpci.c that supports ptn5110 it is in the typec dir drivers/usb/typec… I am on r32.3.1 and the kernel is 4.9.140, where in the generic download not nvidia, the typec dir is missing.
there is not typec dir in the public domain code, so nvidia did some additions to move some functionality into their kernel. The code does match what is in 4.19.2xx so it is some type of hybrid…