USB VBUS always on: camera enumeration fails after a reboot

A custom carrier board that ties VBUS straight to the main 5 V rail puts 5 V on every USB connector before the host controller has a working clock or a driver. The USB3 camera on the other end is already running, yet after every reboot the operating system lists no device until someone walks over and replugs it. That replug is the diagnosis: camera, cable, connector and driver are all fine, and the missing piece is the attach event itself. Here is why the event never reaches the host, the tests that separate it from cable and power faults, and the per-port switch design that ends the unplugging for good.

The symptom, and the two-minute test that confirms it

After a cold start or a reboot the kernel log records no connect event and the USB device list is one camera short. Nothing appears in the log for that port until the camera is unplugged and plugged back in, and the replugged camera enumerates within a second and then behaves normally. Two minutes at the bench turn that into a firm diagnosis:

1. Reboot with the camera attached. The device list stays empty and the kernel log is silent. No attach edge, no enumeration.
2. Replug while the system runs. Instant enumeration proves the camera, cable, connector and host driver all work; only the power sequencing is wrong.
3. Replug does not fix it. You have a different fault. Work through the USB link checks after a cable swap before changing the board design.

Why enumeration is an edge, not a state

A full- or high-speed USB device announces itself electrically: the device pulls the D+ line (D- for low speed) up to 3.3 V through a 1.5 kΩ resistor as soon as it is powered. The host controller sees the line change state and raises a connect status change, and only that event starts enumeration. USB 3.0 adds SuperSpeed pairs for data, but attach is still signalled on the USB 2.0 lines, so the same rule governs a USB3 camera.

With VBUS always on, the camera pulled D+ high while your SoM was still booting — before the host controller was clocked, before its driver loaded, before anything was listening. There was no edge while anything listened, so there is no interrupt, no port status change and no log entry. The camera is stuck on its side too: it never saw VBUS disappear, so its firmware never went through a disconnect and never re-asserted a fresh pull-up. Two ends, each waiting for an event the other has already missed.

Hosts differ in whether they sample line state when the controller initializes, which is why the same camera sometimes enumerates on a desktop port and not on a carrier board. Design as if that sampling does not exist: a board that needs it is a board that fails after the next controller or driver update.

Likely causes in order, and the test for each

Run the tests in this order; each one either confirms the missed-edge diagnosis or points elsewhere:

Cause 4 matters as soon as several cameras share one feed; the bandwidth and power budget for multiple USB cameras article works those sums for a whole harness.

Software-only routes, and where each one stops

Every software route fails for the same reason: nothing in software moves the D+ line.

• Point the port's vbus-supply at the always-on rail. The driver accepts the regulator handle and sequences it faithfully, but a fixed rail ignores enable, so the sequence changes nothing on the wire. The property does real work only when it names a switchable supply — which is the hardware fix below.
• Reset the host controller or reload its driver. Both replay the software state. Neither re-edges the line, so a stack that reports connect on the edge still has nothing to report.
• Connector-class and extcon frameworks. They report connector state upward; they do not create attach events. If the SoM's software release does not enable the framework, there is nothing to configure into working order.

What works without a board respin is moving the switch outside the board: a hub with per-port power switching lets software drop one camera's VBUS and re-edge it, and a relay or switched USB feed driven by a spare GPIO or a controller output does the same for a fixed harness. The three practical arrangements are set out in Power cycle a USB camera remotely: three ways that work.

The fix: a GPIO-controlled load switch per port

Put a high-side load switch between the 5 V rail and the VBUS pin of every connector, and run its enable pin to a GPIO rather than tying it high or low. The core circuit is four parts: the switch, an input capacitor, an output capacitor and a TVS diode across VBUS at the connector. Add ESD protection on D+, D- and the SuperSpeed pairs; the failure modes and parts for that stage are covered in this USB ESD protection and VBUS short-fault walkthrough.

Keep the tie question in view: an enable pin grounded to the board puts the port back to always-on, and the first hung camera costs another walk. A GPIO costs a trace. With the enable on a GPIO and the port node's vbus-supply pointing at the switched regulator, the kernel holds VBUS off until the controller is ready, turns it on, and reads the fresh attach edge it just created — and software gains a power cycle for hung cameras at any time afterwards.

The port's usual resident is a USB3 board-level camera such as:

Size the switch for the port budget, not for one camera; the worked example below sets the number. When the camera reaches the host through a bridge module instead of a native port, the board-level LVDS-to-USB link requirements carry the same power and clock assumptions.

Worked example: sizing the VBUS switch for one USB3 camera

Inputs, with their sources:

• VBUS rail: 5 V — the connector supply on the carrier board in this case.
• Port budget: 900 mA — the USB 3.0 limit for a configured device; before configuration a device may draw only 150 mA, one unit load. Both values are USB 3.0 specification numbers.
• Camera input capacitance: 50 µF — an illustrative value; read the real one from the camera's schematic or measure it at the connector.
• Soft-start ramp: 1 ms — an illustrative ramp for a small load switch; many parts ramp internally in this range.

The rule in words: the switch carries the camera's full draw plus the current that charges its input capacitance, and that charging current is capacitance times voltage divided by ramp time.

Arithmetic:

• I_inrush = 50 µF × 5 V ÷ 1 ms = 0.000050 F × 5 V ÷ 0.001 s = 0.25 A
• I_peak = 0.90 A + 0.25 A = 1.15 A

Decision: fit a load switch rated, or internally current-limited, at 1.5 A or more — 30% above the 1.15 A peak. Check drop and heat at the 0.90 A full-load point for a 100 mΩ part: V_drop = 0.9 A × 0.1 Ω = 0.09 V, and P_switch = 0.9 A × 0.9 A × 0.1 Ω = 81 mW. No heatsink is needed, and 90 mV of switch drop sits inside the ±5% allocation (±0.25 V at 5 V) that a 5 V port is designed to, leaving margin for connector and cable resistance.

Two cameras behind one switch: 2 × 0.90 A = 1.80 A steady, so size that feed at 2.5 A or more, and stagger the two enable GPIOs by a few hundred milliseconds so the inrush events do not add.

Prevention: the rules for the next board revision

• One high-side switch per port, enable on a GPIO — even if firmware asserts the enable at reset, software keeps the power-cycle option for the life of the board.
• Soft-start chosen so inrush stays under half the switch rating — the 0.25 A example against a 1.5 A part does that with room to spare.
• TVS and ESD parts at the connector, on VBUS and the data pairs, not back at the controller.
• vbus-supply naming the switched regulator, never a fixed always-on rail.
• A cable that survives the harness. Where the run moves with an axis, use a drag-chain-rated part such as the LS-CBL-0219, a 3 m high-flex USB3.0 camera cable:

For the rest of the harness — trigger lines, I/O and power — match leads from the camera cables category:

When the camera choice itself is still open, the board camera evaluation checklist runs power, interface and lens decisions in the same order.

Bring-up checklist

Sign the board off only after all four of these pass:

• Scope the VBUS pin at a cold boot: a clean rise over about 1 ms, no overshoot past 5.25 V.
• Count connect events in the kernel log: exactly one per powered port, none repeated.
• Pulse the port GPIO off for 100 ms and back on with the system running: the camera must drop and re-enumerate, proving the software power cycle works.
• Close the camera application, power-cycle the port, reopen it: the recovery path an operator will actually use.

The systems topic page collects more carrier-board and Linux integration fixes like this one. To pick the camera and its cable for a board in design, start at the camera finder and the accessories finder, or go straight to configure a camera and its cabling; harness questions reach the applications team through the contact page.