Adopting a USB hub to extend the TX1 USB0

Hi there,
As Tx1 has very limited USB port, we would need a USB hub attached on USB0 for extend.
USB0 can be Device (act as a download/debug port) or Host (provide power the peripheral devices like a USB camera, a on board DCDC will be needed in such case).

My question is, as soon as I use a USB hub on USB0 (extend 4 USB port, let’s naming them to USB0A/0B/0C/0D), will I lost this HOST/DEVICE switching capability? I mean I would need USB0A as device (for downloading/debug) but USB0B as a HOST (for a USB camera). is there any IC limitation on that or only SW effort?

Tks a lot

Leon

Are you talking about the micro-USB connector or the full-sized USB connector?

You can add one HUB to another HUB for a host. You may run into power draw issues if your devices are bus powered and the HUBs are not self-powered. Having a powered HUB would eliminate a lot of issues for power as several HUBs are strung together.

In the case of the micro-B in host mode where ordinary devices connect to it there is nothing special about its function. In the case of the micro-B in device mode you must remove HUBs, this is a USB definition and the Jetson would become a device (a Jetson in recovery mode is one example of USB device mode because the Jetson becomes a device…a port cannot do both host and device functions at the same time…the OTG spec alternates but is only one type at a time).

I think the theoretical limit for number of USB devices is 99 (I’m thinking in terms of USB2, I don’t know if USB3 changed limits on device count). I imagine data throughput would be terrible.

@linuxdev Thanks a lot for the suggestion.
What I mean is I am looking for the way to extend the USB port not on Nvidia provided carrier board but a customized carrier board (new design).
As we have many peripherals may need USB2.0 port, what Tx1 module provided (total 3X USB2.0, USB0/2/3) are not enough. So adopting a USB hub looks like the only solution.
Reading your feedback, I more or less understand your comments are suggestion on the power the usb HUB–this will not be an issue for a new designed carrier board.
My question would be:

  1. If I extend USB0, since the USB0 is generally for debug/download purpose (Device mode)–that means all extend USB port would be device only mode, correct?
  2. Our application, unfortunately need also TX1 act as host, that looks we need extend the USB2 for host mode.
  3. So by such way, we can use all USB2 extend port as host port and use all USB0 extend port as device port. That adds one extra USB hub but looks meaningful.
  4. Furthermore, for the USB throughput—Would be the throughput inside one USB controller data moving (for exp, from USB2_ex1 to USB2_ext2) better than the data moving across the usb controller (for exp, from USB2_ex1 to USB0_ext1)?

You can use a micro-A/B connector and comply with “On the Go” (OTG) standards to switch mode between device and host mode based on a pin select ID (the cable type plugged in would define if the port becomes host or device, but not both simultaneously).

On the Jetson the micro-OTG port normally runs as host, but in recovery mode the port is treated as device. Technically if the wrong cable type is used the port would be treated as no cable connected. An example is that a type-A connector should function only in host mode, and accidentally using a type-B connector while in host mode should act as if no cable is connected; or conversely, if the supplied type-B cable used for flashing is plugged in while operating in host mode, then anything connected should be ignored. The Jetson is kind of a special case though because the pin select ID is not used to switch modes…modes for the Jetson (unless modified) are selected only by the recovery button being used at power up time.

The shorter answer is that if you put USB0 in host mode you can use it like any other port. If you put the port in device mode you can make the Jetson visible as some custom device, e.g., mass storage. Recovery mode would still put the port in device mode for flashing. The trick is that you have to follow OTG standards and use the micro-A/B connector on the carrier board, and then pay attention to whether you are using a cable with type-B (Jetson as device) or a cable with type-A (Jetson as host)…the OTG connector can do this, the full-sized connectors do not have a pin for ID and cannot do this.

I would imagine having two separate controllers for USB and evenly dividing traffic would be better than using a very large HUB on a single controller…but this only matters if traffic is heavy. Something like a mouse or keyboard won’t care. There are plenty of small surface mount USB controllers out there with up to seven ports on a single chip, but even more examples are available with four ports on a controller. The controller itself does not generally define a port…for that you use a transceiver to handle the physical interface (PHY), and the transceiver can provide OTG switching capability.

Here are a couple of representative lists (I’m not making recommendations, these are just good examples with published information you might find useful, some of those transceivers support OTG which is used for switching via ID pin between host/device mode if software is used to support ID pin host/device context change):
[url]http://www.microchip.com/design-centers/usb/usb-hubs-and-devices/products/usb-transceivers[/url]
[url]http://www.microchip.com/design-centers/usb/usb-hubs-and-devices/products/usb-hubs[/url]

@linuxdev thanks so much for your feedback on this.
One more questions–not sure if you can help?
As you mentioned if we split the heavy data to different USB controller that might able improve the throughput.

I find all TX1 module USB pins from TX1 pinmux spreadsheet as below. I can not find information on what USB controller they belong to?
From X1 datasheet that the USB2.0_Controller#1 are OTG (so it looks USB0 must belong to USB2.0_Controller#1).
But USB2.0_Controller#2 only has HSIC, does that indicate that TX1 USB2/USB3 ports, if belong to USB2.0_Controller#2, there must be a USB PHY used on the TX1 module?


USB 2.0 TX1 Pin # Ball Name Customer usage Note
USB0_D- B40 USB0_DN Primary USB OTG Port USB_controller#1
USB0_D+ B39 USB0_DP
USB1_D- A39 USB2_DN USB2 Host USB_controller#2?
USB1_D+ A38 USB2_DP
USB2_D- B43 USB3_DN USB3 Host USB_controller#2?
USB2_D+ B42 USB3_DP

BR
Liang Ma

This is one someone else will have to answer…I don’t know off hand which maps where.