Hi,
I found something strange about USB 3.0.
If I plug in USB-HUB before the TX2 powerup， everthing looks good, mouse and keyboard are both works well.
But If I pull out USB-HUB and plug it in again,the mouse and keyboard are both works bad.
The dmesg information as follows:
port 1 over-current detected
If I only hot plug mouse and keyboard on this port, nothing bad, why?
thanks.
There is a specification as to what maximum current support is for a USB port (USB3 is higher than USB2, but if a USB2 HUB is used, then it downgrades to USB2 settings even if the port is USB3). Self-powered devices don’t draw USB bus power, and most simple input devices (mouse and keyboard) draw very little power. There are many other USB devices which draw a lot of current (e.g., USB hard drive or a force feedback joystick). What is connected other than mouse and keyboard?
The usual workaround is to get a powered HUB so that power comes not from the Jetson, but instead through the HUB…this allows each port of the HUB to deliver full power…with an unpowered HUB you have the current delivery from a single port on the Jetson being divided among devices on the HUB…the HUB itself also draws some current.
Hi linuxdev,
What I connected is an UGREEN USB-2.0 wired network adapter with 3 ports USB hub, only mouse and keyboard connected to the hub.
For the same base board and USB-HUB, it woks well on TX1, but failed on TX2, is there anything different?
thanks.
Can you try other USB HUB? If overcurrent happens, VBUS gets shut down.
I have tried other three USB HUB, all keep the same situation
Hi cloundliu,
Could you share repro steps?
After bootup and plug-in usb hub, we tried many times, but can’t see the issue.
Test usb hub: Transcend TS-HUB3K
Hi carolyuu,
The BSP version is R28.1, the last kernel commit id is af6c53b9060c2b4a4bda8215ea3cba0d94b5610f.
I have tried it on R27.1 on TX2, it is ok, but failed on R28.1.
I have apply the follow patch to enable usb:
--- a/kernel-dts/t18x-common-platforms/tegra186-quill-power-tree-p3310-1000-a00-00.dtsi
+++ b/kernel-dts/t18x-common-platforms/tegra186-quill-power-tree-p3310-1000-a00-00.dtsi
@@ -106,7 +106,7 @@
pinctrl@3520000 {
vbus-0-supply = <&vdd_usb0_5v>;
vbus-1-supply = <&vdd_usb1_5v>;
- vbus-2-supply = <&vdd_usb2_5v>;
+ vbus-2-supply = <&battery_reg>;
vbus-3-supply = <&battery_reg>;
vddio-hsic-supply = <&battery_reg>;
avdd_usb-supply = <&spmic_sd3>;
test step 1:
test step 2:
thanks.
Hi cloundliu, you don’t need the patch in default carrier board. Can you remove it and try again? Or it happens on your carrier board?
I will try it, but why it works well on R27.1 for the same carrier board?
We apply the same patch.
If you are using default carrier board, the patch is not required for r27.1 and r28.1.
It might be useful for both test cases to show what “lsusb -t” responds with before the unplug/re-plug event. The reason for this is that the speed is shown, and speed is an indicator of what mode is being used…and what mode is being used determines the max current draw for everything on that port.
Hi cloundliu,
Any update? Can it work on R28.1?
Thanks
I want to use the RealSense D435 Camera on my Jetson Tx2.
Therefore i am using a powered USB 3.0 Hub (5V DC)
(this guy: http://www.produktinfo.conrad.com/datenblaetter/1200000-1299999/001234385-an-01-ml-RENKFOCE_4_PORT_USB_3_0_HUB__de_en_fr_nl.pdf) because i use it stand alone with keyboard and mouse over USB 2.0 Connected.
It has four USB Ports and as you wrote @linuxdev when it is powered they all should work.
But in fact i can only plug two USB devices in the USB 3.0 Hub, a third one will not work, even if its a low power device like a mouse or a keyboard.
If i use a USB 2.0 Hub then i am able to plug 3 devices, but of course without USB 3.0 Speed.
So is there something like a maximum number of USB 2.0 or 3.0 devices that the Jetson can handle?
Furthermore it does not make a difference if i power the USB 3.0 Hub, with or without, it can only handle 2 devices on the jetson. I tested it on my host and there it runs…
There are a lot of little things which can go wrong. One area to know a bit about is how USB HUBs are designed…
When a HUB connects to the host as USB3 mode (verify with root_hub as “5000M” under “lsusb -t”) this establishes the maximum speed the host can provide for everything downstream (so if “lsusb -t” shows root_hub as “480M”, then only USB2 mode could be used for everything even if “5000M” is the specification…it would do this if the connected device is not visible as having USB3 mode). This also determines which standard is used for power delivery on the port.
If using USB3 mode on root_hub, then more power should be available than if USB2 mode is shown. However, a HUB which is powered by the Jetson must therefore take in total among all connected devices no more than a single max current draw on the root_hub…the power regulator won’t magically provide full USB3 current to all devices. USB2 mode is significantly less power delivery capability.
USB2 ports tend to support falling back to USB1 or USB1.1 modes directly. When using a USB3 mode root_hub you’ll find USB3 and USB2 devices being plugged in to it use a different driver and route signals to different controllers…it would be the USB2 hardware which is capable of falling back to USB1 or USB1.1. I can tell you that this is not a problem on the developer carrier board.
The place where this starts to get complicated is that the USB HUB you use has an option to use “transaction translators” (a.k.a., the “TT”). Imagine you have a single USB3 HUB, and it is connected to the USB3 root_hub. Now you plug in multiple USB3 devices to the HUB. It would be a simple matter of switching which device is talking to the root_hub…multiplexing or time slice sharing.
Now complicate this by your HUB having both a USB2 and a USB3 device connected. A simple design without a TT implies the entire HUB must back down to USB2 mode…one device next to another device on your HUB can cause the other device to lower its speed. This is where a TT comes in handy.
A TT basically converts higher speeds down to lower speeds and back. It is a speed transceiver of sorts. Most HUBs have at least one TT, even cheap HUBs. Without this the HUB itself would require operating at one speed and could not adapt. If one uses multiple TT (one on each port, versus one for the HUB as a whole), then each port can run at independently different speeds. No two devices would interfere with speed settings when multi-TT. Here’s an explanation you might find useful:
[url]Single Transaction Translator(STT) and Multiple Tr... - Infineon Developer Community
I don’t know if your HUB has multiple-TT or single-TT. However, it is possible a TT could support only USB2-to-USB3 translation…I don’t know if perhaps there is hardware in HUBs which have cut out USB1 and USB1.1 from their TTs. I didn’t see any kind of detailed specification in your URL for your HUB which would say if USB1 and USB1.1 are available…if not, then this might be an odd situation where the TT of the Jetson is able to run USB2 through the USB3 mode connector, and yet the HUB itself might not allow that switch going to lower USB1/1.1 speeds.
The standards themselves for USB3 apply to the Jetson, and there should be no problem with some limit greater than four devices in USB3 mode (perhaps it is limited to 7 devices…or far more). This isn’t to say it would be a “good thing” since that one port has a cumulative max throughput of “5000M” in USB3 mode…all devices together would have to not reach that speed (a mouse or keyboard would be trivial and could be ignored so far as bandwidth requirements go…your cameras could in theory max that out with a single camera…it would depend on the cameras).
There is yet more complication to the story because each device which can operate at a higher speed will essentially provide information about itself to the host when it plugs in (when it enumerates). The mode which is negotiated has different information in order to have backwards compatibility. If you were to use a verbose “sudo lsusb -vvv” to look at any USB3 device, then you would see a USB3 section at the end, and USB2 or slower sections at the earliest descriptive text from the “lsusb -vvv”. If you run the same verbose lsusb for a USB3 device on a USB2 HUB, then the USB3 information will completely disappear. If your USB3 device must run at USB3 speed, then it won’t provide information at all in USB2 mode…it’ll completely disappear and the system won’t know the device is there. This is essentially the same as drawing too much power and shutting the device off…you might get a log entry for being forced off from current draw, but being in USB2 or slower mode when the device only supports USB3 mode won’t offer a single clue…the device is an invisible ghost.
One of the advantages of some communications protocols (including USB and PCIe) is that in some cases if the faster speed results in a loss of communications it can throttle back to the next lower speed…and as long as signal quality is good enough at a slower speed the devices will work (just not as fast). If you have a camera which requires USB3, and if signal quality causes falling back to a slower speed, then the device will disappear just as if the HUB did not support USB3 when the device demands it…the device would be like a ghost with no log messages at all.
You should test each USB3 device one at a time on each port. Monitor “dmesg --follow”. If the system sees each device (with only the one device) from each port one at a time, then you can probably conclude the ports work. Run “lsusb -t” each time to see that each is running at USB3 speeds (the end of the line will show “5000M” for USB3, “480M” for USB2, or slower for USB1/1.1).
If you come up with a port or specific device which doesn’t work, then you might suspect signal quality. Cable quality does matter. Cable length matters as well and mostly can’t be exceeded even with better quality (it’s an issue of latency from longer cables…not other forms of degradation).
Try plugging in just a keyboard or mouse and monitor the same way with “dmesg --follow”. Signal quality and power consumption would be almost unheard of as a problem for these slower signals, but a complete lack of showing up would tend to indicate somewhere in the chain of HUB ports and end port that the earlier/slower protocols simply are not handled.
If you find cameras all work one at a time and all work equally well on each port, then adding one more and testing two at a time, then three at a time fails, then if the devices consume a lot of bandwidth the USB might just be choking on that.
Try testing all of those combinations. Find the specs of your HUB and see if it supports slower USB1/1.1. If you have long or cheap cables for USB3 devices consider replacing them or shortening them as a test.