Depth camera firmware update by DFU: do it safely

A release note lands in your inbox: the depth camera on the cell needs new firmware, and the vendor tool talks about DFU. Done in the right order this is a five-minute maintenance task that ends with a version readback. Done out of order — the wrong file, a hub in the path, a host that suspends mid-write — it ends with a camera that comes back only as a DFU device and a line waiting on a repair. This is the bench sequence for a DFU firmware update on a depth camera: what to gather, how to confirm the file matches your model, the write itself, how long it should take, and the four checks that put the camera back into production on a version your SDK accepts.

When should you update a depth camera's firmware at all?

Update only for a stated reason: a release note that names a bug you can see, an SDK that states a minimum firmware version, or a vendor field notice. A camera that already detects, streams and passes its acceptance checks needs no firmware change.

Firmware sits under everything your application assumes: the depth engine, the USB enumeration, the handshake your SDK performs at startup. The version a camera shipped with is the version your line was qualified against, so a routine stay-current update buys nothing and costs a re-validation. Update when the SDK you are moving to names a minimum version, when a release note fixes behaviour you can reproduce, or when the vendor issues a field notice. Then run your acceptance checks again as part of the update, not after it.

If the trigger is detection trouble, rule out the cheaper causes first: firmware and SDK version conflicts are diagnosed step by step in camera firmware version mismatch: fix detection failures safely, and a full approval-to-readback workflow for a camera fleet lives in camera firmware update workflow from approval to readback.

What do you need before you start?

Gather five things: the firmware image for your exact model from the camera maker or its distributor, the vendor's update tool, a host with a free USB 3 port on mains power, the camera's current version string written down, and ten minutes nobody will interrupt.

In practice that list looks like this:

• The image file for your exact model and hardware revision, from the maker's portal or your distributor. Not a mirror, not a file copied from another project's server.
• The vendor's update tool — usually the same viewer you use daily, in the version the release note names.
• A host on mains power with sleep and USB suspend disabled, a free rear-panel port, and a cable of 2 m or less.
• The current version string from the viewer's info page, with the date next to it.
• A short window in which nobody reboots the host or unplugs anything.

The host matters more than people expect, because the tool needs exclusive access to the port and an uninterrupted power story. A dedicated vision controller mounted near the cell solves both at once: nothing else fights it for the USB stack, and mains power removes the laptop-sleep failure mode. A unit such as the MV-VC2140-128G40-1T is exactly this kind of host, with 2 USB 3 ports and an Intel N-series processor running the tool and nothing else:

How do you match the firmware file to your camera?

The file, the camera model and the hardware revision must all agree. An image written for a sibling model can leave the camera booting only into DFU, which is why the update tool reads the model from the camera and refuses a mismatch before it writes.

Read the model from three places and expect them to agree: the label on the housing, the USB descriptor the host reports, and the info page of the vendor tool. If the model name carries a revision suffix, order the file by the full string, suffix included — the suffix marks a hardware revision and the file sets differ. Where the download page publishes a checksum, compare it before the first write. It costs ten seconds and catches a truncated download that would otherwise fail half-written.

What you are avoiding is the sibling-model write: close enough that the tool's check passes on some cameras, different enough that the depth engine comes back wrong. For what version confusion looks like downstream, after a camera has been swapped between stations, see depth camera firmware mismatch after a shared camera swap.

Structured-light, stereo and ToF depth cameras in our range follow exactly this pattern:

What are the steps for a DFU update?

The sequence is: close every SDK and viewer process, confirm the current version, connect the camera to a direct USB 3 port, let the tool switch it into DFU mode, write the image, leave the camera untouched until the write finishes, then reboot and read the version back.

There is no button to press on most depth cameras. The tool sends a vendor-specific request, the camera detaches from the host and re-enumerates as a DFU device, and its bootloader takes over the flash. From that moment the camera's normal identity is offline, which is why every process holding it must be closed first.

1. Read the current version from the viewer's info page and write it down with the date.
2. Download the image for your exact model from the maker or distributor, and note the exact version string it should produce.
3. Compare the checksum if the download page gives one.
4. Close every process that can open a camera: viewers, SDK examples, your own service. On the production host, stop the service, not just its window.
5. Connect the camera to a free rear-panel USB 3 port. No hub, no extension lead, cable 2 m or shorter.
6. Start the vendor tool with administrator rights and accept the driver it offers to install.
7. Select the image and confirm the tool shows your model and the target version before you start the write.
8. Start the write and leave the machine alone: no unplugging, no sleep, no other USB work.
9. When the tool reports success, let the camera reboot by itself; the first boot after a write can take 10-20 s.
10. Read the version again and compare it character by character with the target string.

How long should the update take?

Budget five minutes end to end and expect about two: the flash write dominates at one to two minutes for a typical 16-32 MB image, while transfer, tool checks and reboot together stay under a minute on a direct port.

The rates below are orders of magnitude for embedded flash and USB. The exact figures are set by the flash controller inside your camera, and the conclusion barely moves between them.

Worked example, for a 16 MB image — a common size for a depth camera:

• Erase and program, at a typical 256 KB/s: 16 MB / 0.25 MB/s = 64 s.
• Verify readback, at roughly 100 MB/s over USB 3: 16 MB / 100 MB/s ≈ 0.2 s; call it 1 s with overhead.
• Transfer of the image itself: even on USB 2, at an effective 35 MB/s, 16 MB / 35 MB/s ≈ 0.5 s. The port speed does not decide the duration; the flash does.
• Detection, model check, mode switch and reboot: about 30 s.

Total ≈ 95 s, about a minute and a half. With the tool open and versions logged, the job is three minutes, and the five-minute budget holds a retry in reserve.

What moves the number: image size scales the flash time linearly, so a 48 MB image writes for 48 / 0.25 = 192 s ≈ 3 minutes; a hub that re-enumerates slowly adds 30-60 s of fiddling; a host that suspends mid-write adds a repair, not minutes. If the tool sits at the erase stage for more than 10 minutes, stop waiting and work the recovery list below.

What do you check after the camera reboots?

Run four checks in order: the version readout equals the target string, the camera enumerates as a depth device rather than as DFU, a depth stream runs for two minutes without a dropout, and one known measurement reads within your normal tolerance.

The known measurement is the one engineers skip and then regret: a depth-engine update can shift the depth scale slightly, and a 300.0 mm gauge block that now reads 300.4 mm is a tolerance conversation, not a mystery. If known distances move outside tolerance, re-run the vendor's on-camera calibration before suspecting the mount. Keep the previous version's measurement log so you can tell an algorithm shift from a mechanical one. For a depth scale that comes back wrong in a specific way, depth scale mismatch: why your point cloud is cut off at close range covers the calibration side.

Two other failures point at the SDK rather than the camera. A stream that opens but decodes badly means firmware and SDK disagree about the data layout; 3D camera header version mismatch: fix firmware and SDK alignment walks that alignment. Depth missing while other streams run is a different path again, covered in depth camera stereo connection: diagnose depth-only failures.

What if the camera is stuck in DFU or not detected afterward?

Most DFU trouble is recoverable. If the tool still lists the camera in DFU mode, run the same write again with the same file; if the host no longer enumerates the camera at all, work down the port-and-driver list before you assume damage.

Work the list in this order and stop when the camera comes back:

1. Re-run the write with the same file. A second pass succeeds more often than not, because a first attempt can stop on a transient enumeration hiccup.
2. Move to a different rear-panel port with a short cable, and keep the hub out of the path for good.
3. Reboot the host before a third attempt: driver state survives camera re-enumerations, and a reboot clears it.
4. Reinstall the vendor driver, or the SDK's udev rules on Linux. Windows in particular keeps a stale DFU driver entry after a failed write; the driver-level fixes for a depth camera not detected after an update apply to that stale-entry case on any depth camera.
5. Try a different host entirely before declaring the camera dead.

For a write that stalls in DFU mode and will not finish, recovering a firmware update stuck in DFU mode walks the same triage on a different device class and is worth ten minutes before you open a support case.

On Linux, two follow-on problems are common and both have clean fixes. A camera that appears in lsusb but not in your SDK is an enumeration-versus-driver question, covered in USB camera in lsusb but not detected by the vision SDK on Linux. And after any re-flash, re-check which device path your application has pinned: re-enumeration can reorder paths, and multiple USB cameras on Linux: stop device path conflicts shows how to pin them by serial number instead.

When should you not run the update yourself?

Leave the write to the distributor's service bench in three cases: the camera has already failed one update, the camera is the only unit on a running production line, or the release note marks the file as service-only for your hardware revision.

A repeated partial write is how a recoverable camera becomes a service case; the vendor's bench has the means to force a clean re-flash that a host tool cannot. Plan fleet updates in scheduled downtime with a spare camera on the shelf, and keep one unit per model on the old version until the new version has passed a full shift of production.

The range this procedure covers, from compact ToF units to laser profilers:

If you are unsure which file matches your unit, contact us with the model and the version string from its info page and we will point you to the right one. To browse first, the camera finder filters depth cameras by type and interface, and the wider integration material sits on the Learn guides hub.