Depth camera stuck in firmware update mode: read the USB ID first

A depth camera that enumerates on the bus but never appears in the SDK usually is not a driver problem, and reinstalling the SDK will not fix it. Read the USB ID first. If the product ID differs from the camera's normal ID and its interfaces come up as vendor-specific class 0xFF, the camera is sitting in firmware update mode, waiting for the maker's updater. This guide shows you how to confirm that from one dmesg capture, how to tell the three look-alike causes apart, and how to run a recovery that ends with the camera enumerating normally again.

The symptom: the bus sees the camera, the SDK does not

The typical report reads like this: the SDK's context call fails with an error about missing video4linux nodes, or returns an empty device list, while dmesg logs a clean enumeration whose product string still names your camera. Nothing changed on the host. Yesterday the same cable and port ran the cell.

That combination points away from a corrupted OS driver. Host drivers bind to a VID:PID pair; when the camera reports a different product ID, the streaming driver has nothing to bind to and the SDK sees an empty bus. The camera is alive and talking, just not as a camera. Read what it says it is.

The two-minute test: read the USB ID

On Linux, three commands give you everything you need:

lsusb
Bus 002 Device 011: ID 1234:0002

sudo dmesg | tail -n 20
usb 2-4: new SuperSpeed USB device number 11 using xhci_hcd
usb 2-4: New USB device found, idVendor=1234, idProduct=0002
usb 2-4: Product: USB 3D Depth Camera

lsusb -t        # bus topology: speed and class per interface

The pair 1234:0002 is illustrative, not a real vendor's. Without sudo, lsusb cannot read the string descriptors, so the Product column may come back blank; that is normal, not a fault. The fields that decide the diagnosis are the product ID and the interface classes:

sudo lsusb -v -d 1234:0002 | grep bInterfaceClass
  bInterfaceClass         255 Vendor Specific Class

On Windows the same fields sit in Device Manager, on the device's Details tab as Hardware Ids; in update mode the entry usually appears under Other devices as an unknown device rather than under Cameras.

You need the camera's normal VID:PID to compare against. It is in the vendor's interface note for the model, or one lsusb run away on a healthy camera of the same model. Record it on the asset label today; every recovery starts with that string.

Normal camera or update mode: what each field says

The vendor ID usually stays and the product ID changes; that swap is the giveaway. Trust the ID, not the product string: a bootloader keeps the name of the camera it belongs to, so a descriptor that still reads 3D Depth Camera proves nothing. Class codes 14 and 255 are USB-IF assignments, so the same comparison works for every depth-camera maker.

Worked example: one capture, three reads

Take the capture above and read it three ways.

First, the product ID. The camera reports 1234:0002 where its normal enumeration is 1234:0001, and every interface answers as class 0xFF: this is update mode.

Second, the speed. The dmesg line says SuperSpeed, so the bus is not the problem; the bandwidth the camera needs is available.

Third, the check that catches the look-alike fault: what a depth stream costs against what each USB speed carries.

For a 640 × 480 depth stream at 30 fps with 16-bit pixels: 640 × 480 = 307,200 px per frame; × 2 B = 614,400 B per frame; × 30 fps = 18,432,000 B/s ≈ 18.4 MB/s; × 8 = 147,456,000 bit/s ≈ 147 Mbit/s. USB full-speed carries 12 Mbit/s, about a twelfth of what the stream needs, so a camera on a full-speed port enumerates but can never stream. High-speed carries 480 Mbit/s, so the same stream takes about 31% of the bus; SuperSpeed carries 5,000 Mbit/s, about 3%.

When dmesg says new full-speed USB device for a depth camera, the cause is a USB 1.x port, a long hub chain or a charge-only cable. The product ID never changed; move the camera to a root port and swap the cable before you blame firmware.

Three cases that look identical from the SDK

For the first case, work through the Linux camera device permission checks, then the USB camera that shows in lsusb but not in the vision SDK; where a second camera or another tool grabbed the interface, the USB busy interface-claim fix covers the hand-off. The third case is wiring, not software.

Recovery: the maker's updater on the OS it supports

The updater finds the camera by its update-mode product ID; the SDK never will, so do not wait for the camera to reappear in your acquisition software. Get the updater from the camera maker's download page for that exact model, nowhere else, and install it on the operating system its release note names. For many depth cameras that is a Windows desktop; if you do not run one, borrow a bench machine once.

Then:

1. Connect the camera to a root port directly: no hub, no dock, no extension cable. Host on mains power.
2. Start the updater and confirm it reports the update-mode ID before you write anything.
3. Let the write run to the end. Do not unplug the camera, sleep the host or close the lid.
4. Power-cycle the camera and run lsusb again: the product ID must be back to the normal streaming ID.
5. Open your SDK and confirm the device is listed and streams.

Generic DFU utilities are the wrong tool. The update interface enumerates as class 0xFF, vendor-specific, which means it does not speak the USB class protocol those utilities implement; they find nothing to open or time out. Driving a captured update stream by hand writes an image with no layout or signature check, and a bad image is what put the camera here. The planned, safe way to run a device update is in the depth camera DFU update guide.

If updates are a recurring part of station life, give them a permanent bench host instead of borrowing a laptop each time. A fanless controller such as the MV-VC2140-128G40-1T provides 2 USB 3 ports and 8 GB of memory, keeps the updater installed between jobs and leaves your development machine untouched.

Why it boots into update mode at every power cycle

Update mode is a boot decision. The bootloader runs first, checks the flash for a valid application image, and jumps to update mode when it finds none, which is why a camera with an erased or half-written image sits in update mode across power cycles until a valid image is written. An interrupted update is the classic cause; a host that slept mid-write does the same damage.

The update environment matters as much as the write itself. For network-attached cameras, the static IP versus DHCP conflict in 3D camera firmware updates is the most common blocker, and the full sequence from approval to readback is in the camera firmware update workflow.

Check depth quality after recovery, not just enumeration. Many cameras store factory calibration in the same flash as the firmware. If the updater flags calibration as invalid, or the recovered depth image bows a known-flat reference, stop: that is a service case for the vendor, not a second write.

Not USB? Ethernet sensors fail on the network path

None of this applies to a sensor with no USB port. Industrial laser profilers attach over Ethernet, GigE on most models, so their look-alike symptom, a device that pings nothing and lists nowhere, is an IP problem: a subnet mismatch, or a DHCP server where the camera expected a static address. Start from the sensor's network settings and the host's interface, not from lsusb.

Prevention: checks before the next update

• Record the normal VID:PID on the asset label now. Recovery starts with that comparison, and it takes one minute today.
• Update only from the maker's release-note package for that model; a firmware file copied through a shared folder has no version provenance.
• Update from a root port with mains power, and disable USB selective suspend in the host's power plan first.
• Schedule updates for planned downtime and close every acquisition process before you start.
• After the write, power-cycle and verify the normal PID in lsusb before the camera returns to the cell.

When to stop and replace

Stop if the updater cannot see a camera that sits at the update-mode ID, if the write fails twice at the same block, or if the product ID never returns to normal after a completed write. At that point the flash or boot block itself is suspect, and there is no field procedure worth the risk of a second bad image. Send the dmesg capture and the updater log to the vendor's support desk and treat the unit as a service case.

If the unit is beyond recovery, the honest decision is a supported replacement. The current Depth / ToF range includes the MV-DT01WMU, and the 3D sensors category covers profilers and stereo cameras if the application is changing too.

The decision, restated

• Product ID changed and interfaces at class 0xFF: firmware update mode. Recover with the maker's updater on the OS it supports, from a root port, without interruption.
• Product ID unchanged but the SDK blind: OS side. Permissions, driver or interface claim; start with the linked checks above.
• Full-speed enumeration or nothing on the bus: port, hub, cable or power. Swap hardware before blaming firmware.
• No USB at all on a GigE sensor: IP and subnet. Work the network checklist.

If you are weighing recovery against replacement, the vision controllers category is where to size a permanent bench host, and the 3D topic guides cover the rest of the depth stack. For a specific camera and a dmesg capture, contact us and we will help you read it.