Problem Observed while using USB hub with JTX1

Hello All,

I am using Jetson TX1 and using USB hub with it.I am connecting Keyboard,Mouse one CAN device and IDS camera with USB hub and USB hub is connected with USB port available on TX1. My observation is many times after connecting all other devices if i connect IDS camera it doesn’t get enumerated and it doesn’t start…

  1. Is this a current issue ?
  2. If yes power adapter comes with TX1 kit is of 19V and 4.74A current output, so can we use adapter of higher output current to resolve the issue…

Any insight is highly appreciated …

USB hosts are designed to limit at a certain amount of current. The limit is far less than the power supply provides (a better power supply to the host will not help). To make additional power available, you’d need a powered HUB (a power supply directly connecting to a HUB is designed to run at a higher output power than one drawing power from the host…standards are designed for this behavior).

FYI, I’ve found various current limiting schemes on USB ports to be unreliable at limiting for the correct current…I try to always use a powered HUB for this reason.

We also observed issue gets resolved by using Powered HUB sometimes.

But what if the issue persist even after using Powered HUB ?

Then the issue is probably software. If the device does not show up even via “lsusb”, some debugging would be required…a wide-open topic that in some cases requires a a USB protocol analyzer, or perhaps just dmesg. This can be difficult because it involves not just the USB “pipe” but other layers informing drivers of a new hot plug device, and how those drivers respond (or don’t respond). More information would be required, especially the response of lsusb (you can use the “-d” option to limit lsusb to a single device, and then get more details with “lsusb -d ‘nnnn:nnnn’ -vvv”, where nnnn is device ID info).

I’ve seen this occur when a call to libusb_reset(…) is made. The xhci can’t reassign a SLOT ID to the device. The device is never detected again until reboot.

What caused the libusb_reset? Was the device physically disconnected and reconnected?

i do not power off the hub when i power down the tx1. i’m thinking it helps some assignments made by the hub to be the same when the tx1 powers up again. but it would only matter if the tx1 creates list and expects list to be the same at power up as was at power down. thing is if i power off the hub my cursor is gone at power up until i unplug the mouse from the hub and plug back in. everything is ok if i leave hub power on.

Assignments won’t change based on whether the HUB external power is unplugged as the Jetson is turned off…the order of enumeration during power on will be the same if the ports are connected the same. But what happens during power on is dependent on what standards the HUB can handle, and what standards the devices are…sometimes.

Your USB 1.1 devices (keyboard, mouse) really won’t draw much power. The USB2 devices might draw more…but I think the power delivery requirements are the same for HUBs (including root hubs on the computer) as to what must be available under 1.1 or 2.0…if not, the 1.1 devices won’t matter much anyway.

Things get trickier when a USB3 device is attached. The standards are not just about speed and how much power the HUBs are required to make available…the trick here is that the device attached to it when the device is USB3 might actually demand more power to operate. When a USB2 HUB is connected to a USB3 root HUB, the root HUB is not what determines how much power your end device is offered…the USB2 HUB would take precedence and run with USB2 specifications (including less power delivery). Even though a device might technically be backwards compatible on USB2, nothing says the device has to work with USB2 speeds, nor does it need to work with USB2 power delivery…it simply can’t cause harm.

So during power up, here is a big question on HUBs and end devices which fail…are any of the devices rated for USB3? Are any of the HUBs limiting you to USB2?

FYI, there are corner cases where a device may not have enough power from raw shutdown to start up, but succeed if power were not removed…e.g., surge current from capacitors charging from a complete stop could consume a pulse of power that interferes with a USB3 device running on a USB2 HUB.

linuxdev,
the hub itself is the only USB3 device that is continually attached. most times at startup just a keyboard and a mouse are attached. i generally try to plug/unplug a USB3 camera i use to learn some of the camera aspects. thank you for the info provided. incidentally, i also have a tk1 with an identical hub and keyboard/mouse setup and the lost cursor on startup happens there under same circumstances. on both devices leaving the hub powered solves that issue.

Having a device attached to a USB3 HUB only guarantees USB3 standards availability if it is operating in USB3 mode…plugging the HUB into a USB2 computer would cause all devices on the HUB to downgrade to USB2 specs even if the device is USB3-capable.

I suspect that standby power on a powered HUB would be a special case…turning the computer off would leave a powered HUB in charge of providing current (a non-powered HUB would inherit the power provided from the computer). In this case, a USB3 device would be detected by the HUB and standby power provided at those levels; once booted, if the root HUB says operate at USB2, most likely only USB2 current would be made available (I can’t guarantee this, you’d have to check each powered USB3 HUB separately to know how it behaves for current supply when in USB2 mode).

About the original post for IDS camera…I’d like to suggest that unless the chain of power delivery is USB3 over the entire chain…preferably with a powered HUB…it may be power delivery is the problem for enumeration. @KapilMehta, when the IDS camera does not enumerate, and you run “lsusb -t”, does the HUB show “5000M” (USB3 speed), or does the HUB show “480M” (USB2 speed)? It would be worthwhile to rule out USB2 getting in the way.