Ubiquitous Successful Bus: Hacking USB 2 Hubs

We’ve been recently looking into USB 2.0 – the ubiquitous point-to-point communications standard. USB 2 is completely different from USB 3, the blue-connector next-generation USB standard. For instance, USB 2 is a full-duplex pseudo-differential bus, and it’s not AC-coupled. This makes USB2 notoriously difficult to galvanically isolate, as opposed to USB 3.  On the other hand, USB 2 is a lot easier to incorporate into your projects. And perhaps the best way to do so is to implement a USB hub.

USB 2 hubs are, by now, omnipresent. it doesn’t cost much to add to your board, and you truly have tons of options. The standard option is 4-port hubs – one uplink port to your host, four downlink ports to your devices. If you only have two or three devices, you might be tempted to look for a hub IC with a lower amount of ports, but it’s not worth bothering – just use a 4-port chip, and stock up on them.

What about 7-port chips? You will see those every now and then – but take a close look at the datasheet. Some of them will be two 4-port chips inside a single package, with four of the ports bottlenecked compared to the three other ports – watch out! Desktop 7-port hubs are basically guaranteed to use two 4-port ICs, too, so, again, watch out for bottlenecks. lsusb -t will help you determine the hub’s structure in case you don’t want to crack its case open, thankfully.

Recommendations? I use SL2.1 chips – they’re available in an SO16 package, very unproblematic, to-the-point pinout and easily hand-solderable. CH334 is a close contender, but watch out because there are different variants of this chip that differ by both package and pinout, so if you’re buying a chip with a certain letter, you will want to stick to it. Not just that, be careful – different variants run out at different rates, so if you lock yourself into a CH334 variant, consider stocking up on it.

There’s no shortage of Western-origin chips, either – Texas Instruments is a leader here no doubt. If you ever fear running out of hub ICs in your stock while assembling something, you can prepare for this in advance by leaving zero-ohm footprints under the hub’s package. USB 2 doesn’t care for stubs much, and such a hack is very easy to do with SL2.1 in particular. Got two extra ports left over? Put them on a PC-case style dual USB2 9-pin header – there’s never a shortage of fun accessories compatible with it!

Powering USB2 hub ICs is easy – they tend to include a 5 V to 3.3 V linear regulator inside, so you can power them from a 5 V source directly. On the other hand, if you don’t have any 5 V to spare, the overwhelming majority of hub ICs can be powered from 3.3 V directly – usually, that requires shorting the hub’s 5 V input to 3.3 V, but not necessarily. If the datasheet is unclear on 3.3 V-only operation, leave in some 0R jumpers. And, of course, make sure to add 100 nF or similar capacitors – one per hub IC’s power pin. Remember the disclaimer about built-in RC oscillators in MCUs being imprecise? Same goes for hubs – if your hub boasts an internal RC oscillator, don’t trust it, make sure you have a crystal footprint you can populate if you get stability issues.

Putting some USB port pins to the outside world? You will want to protect them from harm – or, rather, you will want to protect your expensive CPU from harm.

Please, Consider ESD Diodes

The black SOT23-6 footprint is a group of ESD diodes – small, cheap, and it’s easy to add in case you ever need it, which you very well might.

Bringing USB somewhere far, or even just using it as your link to the external world? You should really use ESD diodes – or at least plan them in and give yourself the option to populate them later. There’s no shortage of USB2-capable ESD diodes, after all, and ESD problems are closer than you might expect.

For instance, I’ve recently built a pocket device consisting of a battery-powered Pi Zero and a USB soundcard connected to wired headphones, with a pretty standard kind of long cable. I wear a lot of synthetic clothes, in particular, hoodies and jackets, and I kept having the Pi reboot every time I took my jacket off or put it on, through static electricity induced into the headphone wires through the cable insulation, going into the USB port on the Pi Zero.

So, I went and put ESD diodes on the USB 2 pins, using the footprint I previously added to my board “just in case” but didn’t populate, and this failure mode has instantly disappeared for good. Remember, footprints are free, and bodges cost time. Want a recommendation? The four-channel diodes are pretty good for USB 2; look for the SRV-05 footprint in KiCad, in the SOT-23-6 package. It’s a generic enough footprint that there’s no shortage of ESD diode packs in the same footprint, they’re low-capacity enough that you can even use it for purposes like captouch pad protection, and they will also work for applications like Ethernet or externally available GPIOs.

Do you need ESD diodes? Yes, just add the footprint. Same goes for over-current control switches, by the way – I’ve already talked about the SY6820, but it bears repeating. Your entire system doesn’t have to reboot when you short-circuit a USB port on the board, and a cheap current-limited switch IC will let you ensure that’s the case, while also letting you switch the port power on and off, as a nice bonus.

This was just a few tips on and around USB 2 hubs and connectors, but I hope it helps you out with your projects.

28 thoughts on “Ubiquitous Successful Bus: Hacking USB 2 Hubs

    1. These are a great brute-force way to slow things down. Say you have to pass USB through the wall of a shielded chamber, and for RF reasons, the passthroughs are filtered to a few tens of MHz. Of course if you put a 480Mbps-capable device in there, it’ll try to link at high speed, and fail, and be miserable! But by having a 12Mbps hub in the way, you slow down the link rate, it works great even through the filtered connection, and you can happily ADB into your DUT….

  1. When looking for a USB 2 hub there is one more thing to look out for: Multi Transaction-Translator vs. Single Transaction Translator.

    This matters when you have multiple low-speed or full-speed (12 MBit/s) devices connected to your hub. Even if the hub itself it capable of high-speed (480 MBit/s) it won’t be able to use this speed to combine the traffic of multiple slower devices if it just has a Single Transaction Translator. It needs the Multi Transaction-Translator for this.

    My cheap go-to hub IC is the Genesys GL852G.

    1. It’s important to note that this is just a full/low speed issue! If you’re the one putting the hub on a board and you know no more than one downstream device is full/low, go for the STT hubs, they can be cheaper. There’s zero benefit if they’re all high speed.

      1. And perhaps the best way to do so is to implement a USB hub.

        I’m still looking for the bottom line. You want USB2 – implement a hub – then what? In what sort of a project would I need this?

      1. Polyfuses have slow activation times, they’re not as protective as an actual switch. You also need to be careful about temp derating: you can get nuisance trips at high T and risk things going boom at low T.

        Really, they’re fine for most cases, but if you’ve got a stock of load switches and the space needed, go with the load switch.

  2. “with four of the ports bottlenecked compared to the three other ports”

    Does cascading USB hubs really cause a bottleneck? AFAIK they are mostly transparent, with very slight round trip delay added per packet.

    1. I don’t think it causes a bandwidth bottleneck because the ‘sharing’ basically happens upstream (the OS sees 7 USB devices, and it shuffles transactions between them equally), but it does generate a tree-depth difference between the two, which can be a problem since the USB spec tree depth is pretty shallow.

      1. To clarify on this: you might think that cascaded hubs would have bandwidth problems like, say, if you cascaded Ethernet switches: if you’ve got ports A, B, C, D and port D has another switch with DA, DB, DC, DD, and they’re all running the same, then the throughput from outside the switch to DA/DB/DC/DD ends up being (1/16th) the outbound bandwidth on average if they’re all fully loaded: the switch has no way of knowing there’s another switch behind it.

        But USB doesn’t work that way – it’s strictly request/response, and the hubs aren’t switches: they just broadcast everything they get from the host, and transmit everything they get from all of the devices. There’s no collision avoidance in the hub – the protocol guarantees that.

        Which means cascaded hubs don’t cause bottlenecks: if you’ve got those same A/B/C and DA/DB/DC/DD devices, the host just spreads the USB transactions equally between all 7. Data doesn’t ‘queue up’ on that one cascaded port, because it has no place to be stored anyway (but as I mention above, cascaded hubs are a problem because the USB tree depth maxes out at 7 tiers, allowing a maximum of 5 hubs between the root and the device, since the root and device each take a tier).

    1. Yeah, I can’t also find anything about it, but I am interested.
      I am also interested in a blog post about how to implement a USB-C PD Sink and 5V source (in the same USB), if you happen to have any good advice

  3. Personally I have had good luck with the Cypress/Infineon HX2VL hub IC (part number CY7C65632, because what is logic). Plonked it down on a design with 2 external ports and 2 internal ports and it worked first try. Here’s my design if anyone needs a reference! https://github.com/mbed-ce/mbed-ce-ci-shield-v2/blob/master/Design%20Files/Rev2/docs/mbed-ce-ci-shield-v2-schematic.pdf
    KiCAD symbol and footprint are available in that repository as well!

  4. While I get the love for sot-23-6, for usb2 specifically, why not use a sot-23-3 based part?

    I did make the mistake of using the TI TPD2EUSB30DRTR which is a usb specific part, but the DRt-3 footprint seems like a challange :/

    1. When protecting a USB port you need to decide between including VUSB or not. With a back to back diode pair (like a sot23) you can’t (not without multiples at least). The SOT23-6 packages can include VUSB as well.

  5. Two things to watch out for when using the SL2.1:
    1) It has only one transaction translator, if you use multiple USB 1.1 peripherals they will share the single 12mbps bandwidth.
    2) If you have a slow usb2.0 device that is unresponsive for a few seconds after power up (eg FPGA needs to boot, ULPI phy chip already on), the hub will switch to USB 1.1 mode on that port after a few resets. Afaik there is no way to get out of this except replugging the device.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.