i'm designing a board that passes through usb-c (one of those framework modules thingies), but internally had a 2.0 hub to connect some other usb ic
a) can i just direct D+ and D- to a 2.0 hub, and pass all other usb-c pins through? (connecting one of the hub ports as the output D+/D-)
b) can i just tap into Vcc from upstream usb without issue? via a dc/dc buck so that usb-pd would still work, so variable input 45V to 5V (i need 5V internally)
b.1) if i can do that, what exactly do i need to do to the CC pin so that things work regardless if something is plugged into the pass-through port or not?
@navi the answer is controlled by your question b.1) - since you'd be "in b4" even a cable, you'd need to "beat" both cable detection, cable *orientation* detection, and device detection… I don't think this is doable without losing some functionality.
…unless the Framework continuously powers its output ports. Which might be the case? The main issue is really to get it to enable power — or, you can steal a few µW from *cable* power (VCONN) rather than *device* power (VBUS).
@navi the USB bus topology getting out of whack is /probably/ not a problem, at least I've seen devices get this wrong before. AFAIR it's a spec violation but nobody cares. The USB2 pins don't care about orientation detection, so that's not an issue either. Unless the Framework turns off the entire USB port (would be very uncommon).
USB-C cable power is unfortunately optional, but if it's there it's there. 3.0-5.5V @ max. 1.25A, one of the 2 CC pins depending on orientation. (You'd need diodes)
@navi so the answer is: you should find out more details about the Framework's USB-C ports.
if it can do 5V 1.25A i could very easily tap from it instead of Vcc, then drop the massive buck converter that was meant to handle 45V~5V into 5V, hmm
@navi they list 20V/5A input ⇒ the ports have to supply VCONN (to power the marker IC for >3A support).
However, the problem then is making it work when no cable is plugged in, without breaking orientation detection when a cable *is* plugged in… you'd need to pretend to be a cable yourself and play some tricks with the CC lines, i.e. do your own detection and either "forward it" (which would likely include a power cycle) or swap the high speed lines if orientation != pretend…
the only thing that confuses me about 3.1 hubs is that they seem to have D+/-, RX1+/-, and TX1+/- inputs, so i'm not sure what to do with the RX2/TX2 pins? (and likewise for wiring the output)
- replies
- 0
- announces
- 0
- likes
- 0
@navi USB3 RX/TX pair choice is determined by which of the CC pins you put Ra on in the cable that you don't have but pretend to 😂
which means for a 3.1 hub i'd leave one of the input set of pairs unconnected, and connect the hub output tx/rx to both output port txrx1 and txrx2?
and a 4 hub doesn't seem to exist en mass yet or at least i couldn't find oen
@navi yes you would leave one pair unconnected (but it has to be the correct one, matching the CC pin which you put 1kΩ on, thereby also making it the VCONN pin)
This is also what limits downstream functionality; ideally the hub IC you choose has built-in USB-C port support or you have a bunch of mucking about ahead of you…
btw: some STM32G0 have 2 USB-C/PD controllers. But putting yourself in the middle doesn't solve orientation swap, and is a whole bunch of coding to relay messages…
use a usb 3.1 hub and a usb-pd trigger ic, tap from either vcc or vconn
or
use vconn relying on 1.5A, and do smth with mosfets or smth to detect downstream port oration and reset the whole thing on connection
@navi STM32G0 w/ 2× PD controllers + orientation crossover mux + a whole bunch of coding would do it reasonably reliably and maybe even in spec (without a USB3 hub - so you'd even get to keep DisplayPort/TB functionality)
@navi also to be clear, the yes doesn't apply to this part:
"connect the hub output tx/rx to both output port txrx1 and txrx2"
You can _never_ connect a diffpair like that. The downstream port needs a mux and be able to switch the high speed lines to the correct pair on the port, after you detected which one by looking for Ra on both of the CC pins and finding it on only one.
@navi (the _never_ applies to all diffpairs in all contexts; if you are in an exception you will know about the exception and not be asking the question 🙂… just consider them strictly limited to point to point connections with the exception of a termination resistor if the protocol specifies that. Applies equally to USB3, USB4, diff clock signals, PCIe, DisplayPort, etc.)
@navi for the second option, you can either powercycle the device and try to match the cable orientation (tricky… how do you swap Ra around while losing power…), or include a 2×2 crossover mux on the highspeed lines (& SBD if you want DP to work, not sure if USB4/TB uses them).
@navi you're not picking a particularly easy first project there 😅
Maybe just straight up USB hub IC with integrated USB-C support (e.g. USB7252C) is the best approach… even if it means losing power input & alternate protocols on that port
considering i don't plan on using it on the high power capable ports (top two), i could make a v1 with the 3.1 hub (and maybe even add a second output port, those are lacking in this laptop)
and if i feel the need of more, do a v2 with the muxer instead
@navi I'm confused… smartcard… as in ID-1 full sized? That's too large for the Framework module thingies, no? … and if it's dangling externally… what's the benefit? Or are you planning on mini/micro/nano SIM sized smartcards only?
@navi ah ok I was thinking within the box², while you aren't
² metaphorical and physical 😂
@navi you don't need to communicate on CC to get plain USB3 up to 20G; if you have a captive cable you only need the 1kΩ Ra on one of the two CC lines to make the host to use its (likely built-in) mux and put the high speed diffpairs on the right pair, and the appropriate Rd to identify as a device.
If the upstream port is not a captive cable, rather a USB-C socket, that also needs the mux & be able to detect Ra in the cable. (This is why cheap USB3 hubs with USB-C have fixed attached cables.)