The comms problem is indeed fixed when the STM32F7 is connected via a hub. (I've tried two: an LG display and a discrete USB-C hub.)
The STM32F7 is configured for HS mode though (480 Mbps), so I'm not sure how that affects your theory?
I've never discovered the underlying reason – I don't have sufficient test equipment either to do a comparison or measurement on the actual signals –, but I
suspect it is related to timing, and how high-speed USB hubs need to reclock the signal. I suspect it is not exactly a frequency issue, but something to do with jitter, i.e. timing on individual symbols, not average symbol timing. If so, you might need a 1GHz+ scope to tell.
USB 2 high-speed signaling is half-duplex; there is only one signal pair (D+ and D-), which transfers data in one direction at a time. Theoretically, the high-speed symbol rate is 480 Mbit/s ± 0.24 Mbit/s, or ±0.05% or ±500 PPM, but I
believe many USB 3 host chipsets just require stricter timing than that for reliable transmission. (At full speed, the symbol rate is 12 Mbit/s ± 0.03 Mbit/s, or ±0.25% or 2500 PPM. A full-speed USB 1.1/2.0 hub does not need to retime/resync the signals, but a high-speed one always has to, and such hubs almost invariably use a crystal for this. The MCUs I've personally observed this happened to also used proper 16MHz or 24MHz crystals, integer fractions of the 480MHz symbol rate, and worked fine with some USB 3 host implementations and only had issues with some others, so they cannot have been too wildly off. I can imagine a PLL sync'd to say a 27 MHz crystal might easily be off by more than 500 PPM, though, as the exact ratio is then 160/9 ≃ 17.778.)
It is also possible the USB 3 host chipsets are within spec, but the microcontrollers out, and all hubs (I haven't found a USB 2 HS hub that would not fix this issue) are more tolerant than those host chipsets.. but considering this only affects only some (mostly USB 3.0) host chipsets, used to be much more common with early USB 3.0 chipsets, and
all USB 2 HS hubs seem to fix this issue, I'm inclined to blame the USB 3 host chipsets.
This used to be common when USB 3 was first introduced, with the "use a hub in between" being recommended for all kinds of issues with even standard mice and keyboards. With the next generation host chipsets (for USB 3.1) problems were much rarer, and with current chipsets very rare. It is quite possible the same problem would have affected USB 2 HS devices, if we'd have any; at the time, MCUs like AVRs with native USB had only full-speed support, and even today many (most?) ARM Cortex M0/M0+/M3/M4/M4F microcontrollers tend to have only full-speed USB, with high-speed appearing mostly with Cortex M7 and later cores (and of course in specialized chips like Cypress FX2).
TL;DR:
Apologies for not being able to give any actually reliable information; only that "use usb 2 high-speed hub" used to be a common fix for a similar issue with all sorts of USB 1.1 full-speed devices (USB 2.0 high-speed ones being rarer), when USB 3 was first introduced.
Home
Help
Search
Login
Register
