USB3 hub disconnects right after detection on the board's USB-C port

You plug a self-powered USB3 hub into the USB-C port of an embedded Linux board. The kernel finds it — two root buses come up, the hub reports its 7 ports — and about a second later the port is empty again. This guide walks that failure in the order the log supports: what the dmesg lines mean, why a drop this early is an attach-phase fault rather than a bandwidth one, and the three causes worth testing — host-role latching, upstream VBUS, and the USB-B to USB-C cable. You finish with the meter points to probe, the settings to change, and the point at which to stop and move the cameras to another interface.

What the log actually says

An xHCI controller with SuperSpeed registers two buses: a high-speed USB 2.0 companion and the SuperSpeed bus itself. Each is a one-port root hub behind the same physical connector, which is why the log prints 1 port detected twice. A USB3 hub must come up on both. Trimmed to the lines that settle the diagnosis:

hub 3-0:1.0: 1 port detected
xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 4
usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
usb 3-1: new high-speed USB device number 2 using xhci-hcd
hub 3-1:1.0: USB hub found
hub 3-1:1.0: 7 ports detected
usb 3-1: USB disconnect, device number 2

Two findings matter. First, there is no new SuperSpeed USB device line anywhere on bus 4: the SuperSpeed pairs never trained, so the hub only ever attached at the 2.0 rate. Second, the drop happened with the hub idle — no camera, no stream, no load. The LPM line is noise: the kernel switches off USB 2.0 link power management when it lacks the host's algorithm, which costs a little idle power and nothing else.

Worked example: this hub lived 0.79 seconds

Inputs, straight from the log timestamps (kernel time, seconds): attach at 251747.661951 s (new high-speed USB device number 2), hub descriptors done at 251747.842300 s (7 ports detected), disconnect at 251748.455360 s (USB disconnect, device number 2).

The rule this feeds: classify by when the drop lands. Idle, under a second after clean enumeration, means the attach handshake failed — role, VBUS or link training. Power and bandwidth faults land later, seconds to minutes into streaming, with frames already moving.

Result: this hub was fully described and idle when the link dropped, 0.79 s after attach and 0.61 s after its ports were counted. The decision follows directly: treat it as an attach-phase fault and work role, VBUS and cable. Packet size, host receive buffers and frame-rate limits change throughput numbers, and this link never carried a byte of image data.

Cause 1: the port never latched as host

A USB-C dual-role port picks host or device from the CC pins: the host side presents a pull-up, the device side a pull-down. A captive USB-B to USB-C cable presents the device-side resistor at its C plug, so a healthy dual-role board settles into host mode with this hub attached. What the silicon actually does comes from firmware. On this class of board the controller driver — the DWC3 family — reads a dr_mode property: host, peripheral or otg. Under otg the port negotiates its role on every cable event, and a decision that lands late, or re-triggers after enumeration, drops the bus exactly this way.

Pin the role. Set dr_mode to host for that controller in the board's platform configuration and reboot. Some vendor kernels also expose a runtime role file under the controller's sysfs directory — fine for a quick test, then persist the change so a power cycle cannot undo it.

Success has a signature: two hub enumerations. The high-speed one you already have, plus a new SuperSpeed USB device line on the second bus. Force host, replug, and watch for both. Note the negative result too: if forcing host makes the port go silent — a flash drive stops enumerating as well — the fault has moved below the role logic to the VBUS path in the next section. Device mode still working against a PC proves the PHY and the connector are good.

Cause 2: upstream VBUS never arrives

A self-powered hub never drives its upstream line. It watches VBUS to know a host is attached, and detaches cleanly the moment 5 V disappears. If the board's VBUS comes up late, never, or sags when the hub's input capacitors charge, the log looks exactly like this: full enumeration, then a polite disconnect.

Meter it. Port forced to host, nothing else attached, measure between VBUS and GND at the connector: a compliant host port holds 4.75 V to 5.25 V, the ±5 % window on 5 V. Zero volts means host mode never engaged the port's power switch — a board firmware or board design fault that no cable will fix. A rail that reads fine unloaded and dips on attach points at the board's 5 V supply or its load switch.

The mirror-image fault exists too: boards that leave VBUS permanently on break enumeration in the other direction, covered in USB VBUS always on: camera enumeration fails after a reboot.

Cause 3: the USB-B to USB-C cable

This cable fails two ways, and only one of them explains the drop:

• USB 2.0-only or charge-only construction. No SuperSpeed pairs wired, so the hub can only ever attach at high speed — which is the missing new SuperSpeed USB device line. It does not by itself cause the disconnect; it pairs with cause 1 or 2. Behind such a cable the whole hub shares 480 Mbps, which is 60 MB/s in theory — no machine-vision camera stream fits that.
• Marginal pairs or flaky CC presentation. The link retrains and xHCI resets the port. That pattern repeats connect and disconnect over minutes rather than dropping once cleanly; USB-C cable timeouts on a USB3 camera works that case on the camera side.

The test that splits board from everything else: same hub, same cable, into a PC. Both enumerations on the PC prove hub and cable, and the fault is the board's port. No SuperSpeed on the PC either means the cable goes first — the most common failure and the easiest swap. For the permanent install, match the cable to the movement it will see; on a machine that flexes, use a high-flex drag-chain USB3.0 camera cable:

The fix sequence, in order

1. Prove hub and cable on a PC host. Confirm both the high-speed and the SuperSpeed enumerations before touching the board.
2. Force the port to host: dr_mode set to host for that controller, or the board's boot-time role setting, then reboot.
3. Meter VBUS at the board's port as in the VBUS section — host mode forced, port idle.
4. Replug the hub and watch for both hub enumerations. Any USB disconnect in the first minutes sends you back to step 2 or 3.
5. Attach one camera and confirm it lands on the SuperSpeed bus, not as a high-speed fallback — the fallback pattern is covered in Camera enumerates as USB 2.0 on a USB 3.0 port.
6. Soak it: stream at full resolution for half an hour with the log open. An idle-port pass says nothing about behaviour under load. If the port still will not hold, stop spending time on it and change the camera interface.

What the hub can carry once it holds

Plan against the USB 3.0 spec numbers, not the marketing ones:

Every port shares that one upstream link. Work a typical sensor through it: 4000 x 3000 pixels x 30 frames/s x 1 byte per mono pixel = 360 MB/s. One such camera fits; two is 720 MB/s against 500 MB/s and does not. Plan one full-rate camera per USB3 controller, spread cameras across controllers, or pick an interface with headroom. How several cameras share a hub — per-port budgets, which cameras pair — is the subject of USB3 hub bandwidth for multiple machine vision cameras; the host-side view is Multiple USB cameras on one host: bandwidth and power budget. A camera drawing beyond the per-port budget needs its own supply — the trade-offs are in Camera power: USB versus external 5V.

For the soak test, any USB3 area scan camera tells you whether the link holds:

When the usual answer is wrong

• Swapping the hub. The log read its descriptors and counted 7 ports before the drop; dead hubs rarely enumerate that far. The hub is the least likely part on the bench.
• Tuning the host. Raising USB receive buffers and packet sizes fixes streams that drop frames at full resolution — Two USB3 cameras at full resolution stream is that problem. An idle drop in the first second is not.
• Adding hub supply. The hub is already externally powered; the supply it watches is the board's 5 V on VBUS.
• Endless cable swaps after host mode silences the port. When a flash drive also fails while device mode to a PC still works, the board is not completing host mode — no cable fixes that. The camera-side twin of this symptom is worth a read before you blame hardware.

The escape hatch is a different data path. GigE cameras on locking-RJ45 machine vision cables leave the board's USB port out of the image path entirely: the LS-CBL-0117 is a 15 m example with a locking stud, and GigE Vision camera not detected in software covers the enumeration chain you will meet first. Replacement cables of every type sit in the accessories finder.

Checklist before you replace anything

• Hub and cable proven on a PC, with both enumerations — isolates the board in one step.
• dr_mode pinned to host for that controller, then a reboot — removes the role negotiation that drops the port after attach.
• VBUS measured in the 4.75 V to 5.25 V window in host mode — proves host mode engaged electrically, not just in the log.
• One camera on the SuperSpeed bus, not a high-speed fallback — the reason the hub exists.
• Half-hour full-resolution soak with the log open — an attach-phase pass predicts nothing under load.
• Per-port power within the 4.5 W budget, or external camera power — the number that decides whether the hub feeds the camera.

When the port passes all of this, the hub is ready to carry cameras; when it does not, the fastest route to a working cell is a different interface. The system configurator walks camera, cable and power in order, and the contact page puts the log in front of our applications team — expert support is free with every order. More field-side failures like this one sit under the systems topic.