Depth board firmware update: fix enumeration errors

A depth camera built from a separate processor board and a depth module fails in a characteristic way: the firmware updater cannot enumerate the device, and the board appears in the OS as a tester entry instead of a camera. The error looks fatal and almost never is. This page is for integrators bringing up that two-piece rig. You will decode each symptom, update the processor board on its own with the signed image that matches its update-mode USB product ID, re-attach the module, and verify the version took. The whole rescue is a USB job: one root port, one short cable, usually well under half an hour.

What the enumeration error actually says

Three symptoms travel together. The updater's device list either shows an entry whose name ends in Tester, or it fails the moment it tries to open the first device listed. The SDK side fails harder: a call passes a null device argument, then an error reports that a property set does not exist for the object. The error text follows the operating system's language, which is why it can arrive in a language you never installed.

All three come from one fact. The entry the tools see exists at the USB level but carries no camera properties, because the board is presenting its factory update-mode identity rather than a camera identity. A tool that expects a camera asks that entry for properties; the board has none to give; the call fails with a message about a property set, not about a cable. Read it as: the board is alive, in update mode, and not yet a camera.

If the device instead sits in update mode and will not leave it, that is a different fault; start with the depth camera stuck in firmware update mode guide.

Likely causes, in order of probability

Work down this list; the first cause explains most cases.

1. Image and device ID mismatch. Signed firmware images are keyed to a USB product ID. A board in update mode presents its tester ID; an image built for the finished camera carries the camera's ID. The updater compares the two and refuses at the handshake, before writing anything, and that refusal shows up as your instant enumeration error. Test: read the product ID from the tester entry in the device manager or lsusb, then compare it with the ID the image you have targets.
2. A ghost entry from an earlier failed session. The list shows a device that cannot be opened because it no longer exists on the bus. Test: detach the module, replug the board, and count the entries; one that vanishes after a replug was stale.
3. A USB link that cannot survive the mid-update reset. Updaters reset the device partway through, and hubs, case front panels and long passive cables are where the reconnect fails; the error text says the sensor did not reconnect in time. Test: move to a root port with the short cable. The USB bandwidth and power checklist covers the port-side faults behind this.
4. Another process holding the interface. Capture or preview software keeps the device claimed, and the updater cannot take exclusive access. Test: close every capture program, then list again. The claim-error pattern is the same one behind the USB busy fault with two depth cameras.

The fix: update the board alone, against its own ID

1. Detach the depth module from the processor board. The update targets the board; the module has no part in it.
2. Connect the board alone to a root-port USB socket with the short cable, no hub. Confirm the tester entry in the OS device list and note its vendor and product ID.
3. Download the signed firmware image published for that update-mode ID, from the manufacturer's own firmware release page. A mirror or a file passed around a chat thread is how wrong-ID images end up on benches in the first place.
4. List devices with the updater and expect exactly one entry. Zero entries means the USB path needs work before anything else can happen.
5. Run the update with that image and leave the cable alone until the updater reports done. The device will drop off the bus on the way; that is planned, and the next section puts numbers on it.
6. Confirm success and check that the board now enumerates under its processor identity rather than the tester name.
7. Re-attach the depth module and seat the board connector and interposer fully; the module and processor board pairing guide covers the mechanical checks.
8. Verify: list devices once more, read the firmware version, and run one capture.

What each rig state should enumerate as

One device per state is the rule; a count other than one tells you which stage failed.

The timing that decides the outcome

Updaters for this class of camera reset the device partway through the write, and near the 30% mark of the progress bar is typical. That drop is where most rescue attempts go wrong, so put numbers on it:

At the reset point, 70% of the image is still to be written, and unplugging there guarantees a half-written board that returns only as a tester entry. If the run fails with a did-not-reconnect message, that text names the reconnect window the updater waited; give a rerun the full window before you touch anything. Rerunning the same image is safe because the write starts over, so a refused or interrupted attempt leaves nothing a second pass cannot overwrite.

Mistakes that stretch the job into an afternoon

• Updating the assembled pair. The composite enumerates unpredictably; the board-alone path exists to avoid exactly that.
• Trying every image in the folder. Each refusal is the ID check working. Read the tester entry's product ID and fetch the image published for it.
• Updating through an unpowered hub or a case front panel. The mid-update reset draw is where marginal ports fail.
• Reinstalling or rolling back drivers while the bar is moving. Clean stale entries only after the board settles.
• On a network-attached depth camera, letting DHCP move the address mid-session; pin a static address before the update.

If your board updates through DFU rather than the vendor updater, the sequencing differs; follow the DFU update safety walkthrough instead of the steps above.

After the update: pair, verify, then trust it

With the module re-attached, confirm exactly one camera entry, then read the version back through the SDK and compare it against the image you ran; the two must agree, digit for digit. Check the SDK against that version before blaming the camera; an older SDK under newer firmware fails later with header or property mismatches, which the firmware and SDK alignment guide untangles. Finish with one capture at your working distance. An enumeration that survives a capture is one you can build on.

When to stop, and what to buy instead

Stop when one of these holds. The board lists nothing on any computer, cable and root port you try; that is board hardware, not firmware. Or the manufacturer publishes no image for your board's update-mode ID; only the board maker can publish that file, so take the ID to them. Everything else on this page is recoverable.

If the rig is a development pair and the project needs uptime more than it needs the pair, an integrated depth camera removes the module-to-board interface altogether. The 3D sensors category covers laser profilers, structured-light and ToF cameras, the 3D camera finder filters them by type, and the system configurator at the camera step chooses camera, lens, light and controller together.

The MV-DT01WMU is a ToF sensing camera, and the MV-DPS200P-02 is a projected structured-light 3D camera. Each is a single integrated camera rather than a module-and-board pair.

The 3D vision topic page collects the surrounding guides; to talk a rig through before ordering, use the contact page.