USB3 falls back to USB 2.0 speed: fix the SuperSpeed pairs

A USB3 device that enumerates but runs at 480 Mbps, or throws errors when plugged in directly, is telling you its USB 2.0 pair works and its SuperSpeed lanes do not. On stock hardware the cause is almost always the cable, the seating or a hub. On a custom carrier board it is most often the SSTX and SSRX differential pairs swapped at the connector, and no driver can recover that. This guide gives you the test order, the connector pinout to audit against, and the fix for each cause — written for anyone bringing a machine-vision camera up on a board they had built.

The symptom: one link works, the other does not

A USB 3.2 Gen 1 connection is two independent links in one shell. The four contacts at the front of a Standard-A receptacle (VBUS, D-, D+, GND) carry the 480 Mbps USB 2.0 link. The five behind them carry the 5 Gbps SuperSpeed link. The two links train separately, so when the SuperSpeed lanes fail, the 2.0 pair keeps going and the device enumerates at roughly a tenth of the speed.

That split explains every version of the symptom:

• Direct connection, errors. The device retries SuperSpeed training, never succeeds, and floods dmesg with enumeration errors.
• Through a hub, "works" at 2.0. The hub's upstream SuperSpeed port fails the same way, the hub re-enumerates as a USB 2.0 hub, and every device behind it inherits the 480 Mbps cap.
• Trains, runs, then drops mid-transfer. That is signal quality, not lane direction, and it needs a different fix (step 6 below).

If you see the first two bullets on a board you designed, go straight to the pinout audit in step 4 before touching a single driver. For the same symptom on a known-good port, start with camera enumerates as USB 2.0 on a USB 3.0 port.

What the fallback costs a camera

Gen 1 moves 5 Gbps on the wire in 8b/10b encoding, so the payload ceiling is 4 Gbps (500 MB/s), and cameras in practice sustain 350-450 MB/s. High speed moves 480 Mbps, and bulk traffic on it lands at 35-40 MB/s. The line rate drops tenfold; usable throughput drops by more.

Take a 12 MP sensor running 30 fps in 8-bit mono. 4000 × 3000 pixels × 1 byte = 12 MB per frame. At 30 fps that is 12 MB × 30 = 360 MB/s. On the wire: 360 MB/s × 8 = 2.88 Gbps of payload, × 1.25 = 3.6 Gbps — comfortable under the 5 Gbps line rate, which is why a camera of this class is a USB3 camera at all. On a fallen-back link at 40 MB/s, 40 ÷ 12 = 3.3 fps. Same camera, same settings, one wiring fault: 30 fps becomes 3.

A 12 MP camera such as the LS-CMR-0166, streaming 4000 × 3000 frames at 30 fps, carries exactly that load.

The fallback can also hide behind a cropped region of interest: 1600 × 1200 × 20 fps × 1 byte = 38 MB/s, which fits inside high speed. Then someone restores full resolution and the frame rate collapses. When frame rate degrades over a shift instead of at power-on, read camera FPS drops suddenly: exposure, USB link, bandwidth.

The nine contacts and the one swap that matters

The rule that gets broken: the host controller's transmit pins go to contacts 8 and 9, its receive pins to contacts 5 and 6, straight through. The crossover from host transmit to device receive happens inside the cable, never on the board.

The trap is the micro-B end. On a micro-B device receptacle the order is reversed: contacts 5 and 6 are the device's transmit pair, 8 and 9 its receive pair. Copy a device-side connector symbol into a host schematic and the pairs come out swapped — the layout passes every design rule and the link never trains.

What the link can and cannot forgive:

• Polarity inside a pair is free. A receiver detects inverted polarity during link training and compensates, so TX+ landing on the TX- contact still runs at full speed.
• Direction is not negotiable. The SerDes lane direction is fixed in silicon; no driver, register or equalizer setting turns a receive lane into a transmit lane.
• Both pairs crossed — transmit on 5/6 and receive on 8/9 — is the classic: direct connections error out, hubs fall back to 2.0.

While you are in the schematic: the SuperSpeed pairs are 90 Ω differential, length-matched within and between pairs, with the AC-coupling capacitors the specification requires in series on the transmit lines. Route them away from motor-drive and switching-regulator noise. The habit of checking pin assignments before a board mounts applies to vision I/O boards too — see camera IO board pin alignment.

Test in order of probability

1. Read the negotiated speed. On Linux, lsusb -t prints the device tree with each device's negotiated speed: 5 Gb/s means SuperSpeed, 480 Mbps means the fallback. Watch dmesg as you plug in; a burst of enumeration errors on a direct connection is the signature of lanes that never train. If the tree already shows SuperSpeed and throughput is still poor, you have a bandwidth problem, not a fallback — start at USB3 Vision transfer errors: diagnose bandwidth and buffers.
2. Swap in a known-good Gen 1 cable. A USB 2.0-only cable has no SuperSpeed pairs and reproduces this exact symptom on healthy hardware. Push the plug home in one firm motion; sliding it in slowly can leave the rear contacts half-mated and the link at 2.0. Keep passive runs at 3 m or less on a machine.
3. Bypass the hub. Check the hub's own entry in the tree: if the hub reads 480 Mbps, its upstream SuperSpeed link failed and every camera behind it inherits the cap. When several cameras share one hub, budget the bandwidth as well: add up each camera's stream in MB/s and keep the total inside the roughly 400 MB/s that one Gen 1 upstream link can sustain, or split the cameras across host ports.
4. Audit the SuperSpeed wiring. Power the board down and wear a grounded wrist strap. Ring out continuity from the controller's transmit pins to contacts 8 and 9, and from its receive pins to contacts 5 and 6, against the module vendor's reference schematic. The transmit lines carry series coupling capacitors whose pads make clean probe points; probe the receive pair from the receptacle pads back toward the controller. Transmit ringing out on 5 and 6 is your answer.
5. Fix the port role. A Type-A port has no PD controller to negotiate roles at runtime, so it must be set to host-only mode in the device tree. A port that stays dead or errant with every device you try points here rather than at wiring: USB3 port dead on a custom board: the device tree phy-names mismatch.
6. Run the compliance test. When a link trains and then drops, or only works with a short cable, measure the transmitter eye and jitter with the compliance-test procedure the module vendor publishes. Marginal eyes pass at boot and fail warm, at the end of a long cable, or next to a running drive.

The fix for each cause

• Swapped TX and RX on a built board. Prove it on one prototype: cut the four SuperSpeed lines and jumper them crossed, keeping the jumpers short, and confirm SuperSpeed in lsusb -t. Then correct the connector symbol in the netlist and respin. There is no software path around a lane-direction fault.
• Marginal eye. Shorten the run, reroute the pairs away from switching regulators and motor drives, and retest. Receiver equalization settings, where the controller exposes them, can recover a marginal link; they cannot rescue a bad layout.
• Port role. Set host-only mode for the Type-A port in the device tree, re-flash, and confirm SuperSpeed with lsusb -t before commissioning.
• Cable or hub. Replace with a Gen 1 camera cable and give cameras dedicated host ports instead of shared front-panel wiring. The LS-CBL-0219 is a 3 m USB3.0 camera cable rated for drag-chain use on a moving axis; the MV-GU2204 is a quad USB3.0 adaptor with 4 ports for exactly that segregation.

For everything else in the chain, browse cables and the accessories finder; USB3 frame grabbers and host cards cover the dedicated-port route as well.

Checklist before the next spin or cable order

• Connector symbol pinout cross-checked against the datasheet of the exact receptacle you mount: Standard-A host ordering differs from micro-B device ordering.
• Host transmit on contacts 8/9, host receive on 5/6; polarity inside each pair left as routed.
• 90 Ω differential pairs, lengths matched, coupling capacitors on the transmit lines.
• Host-only mode set in the device tree for every Type-A port.
• Negotiated speed confirmed with lsusb -t at full camera resolution during commissioning.
• Passive cable runs at 3 m or less, drag-chain rated wherever the camera moves.

For cameras and hosts, the camera finder and area scan cameras list current USB3 models, and the system configurator walks the chain from camera to cable.

When 480 Mbps is not the fault

• The tree already shows SuperSpeed. Your stalls are then bandwidth or buffer problems: on Linux the usbfs memory limit caps how many large buffers a USB3 Vision camera can queue — USB3 Vision cameras on Linux: usbfs and file limits that need tuning.
• The payload genuinely fits high speed. A 1600 × 1200 region at 20 fps in 8-bit mono is 38 MB/s, inside the 35-40 MB/s high-speed budget. The task completes; still specify Gen 1, because resolution grows and the margin is easiest to add now.
• The device is USB 2.0 by design. Some board-level sensors and code readers top out at 480 Mbps; for them that is the ceiling, not a fault.

The decision, case by case

• Stock host, commercial cable: swap the cable, reseat firmly in one motion, bypass the hub. Most cases end here.
• Custom carrier board, direct errors plus hub fallback: swapped SuperSpeed TX and RX at the connector. Audit contacts 5-9 against the controller pins, prove it with a crossed jumper on one prototype, respin.
• Link trains, then drops: signal quality. Run the compliance test, then fix length, routing and noise.

If the port still falls back after a clean pinout audit and a known-good cable, take the lsusb -t output and the connector pinout to the contact page.