Downgrade a tracking camera firmware version: why the replug matters

You rolled the firmware back, the update tool reported success, and the camera still reports the build you tried to leave. That gap between what was written and what is reported has one dominant cause: the firmware image loaded in the camera keeps running until the camera loses power, so the version readback cannot change until you unplug the cable and plug it back in. This page is for anyone maintaining tracking or depth cameras on a bench or in a cell. You will learn why the replug decides the outcome, how to test the two remaining causes in order, and how to tell the rare case where a rollback is genuinely blocked.

Symptom: the write succeeds, the readback stays old

The signature is consistent. The SDK's firmware tool runs its progress bar and reports the update complete. The viewer, reopened seconds later, still lists the previous build — in the case behind this guide, 0.2.0.951 after a rollback request for 0.2.0.926. Running the update again changes nothing, and reinstalling the SDK changes nothing.

The camera otherwise behaves normally: streams, pose output and parameters all work. That detail matters, because a camera that works but reports the old version has almost certainly written its flash correctly — the stale number is the loaded image, still running. A camera that vanishes from the bus or sits in a bootloader is a different failure, covered in depth camera firmware update by DFU: do it safely.

Why the loaded image outlives the write

A tracking camera holds two firmware states. One sits in flash: non-volatile memory, and the only thing the update tool writes. The other is the image loaded into the processor at power-up, which runs until power is removed. Tracking cameras take that image from the host: the SDK loads its bundled firmware into the camera when the device connects, and the loaded copy survives disconnects, application exits and driver restarts.

So a rollback writes the older build to flash and reports success, while the newer image loaded at the last power-up is still the one answering the version query. Nothing in software changes that. A closed viewer does not, an exited application does not, a rebooted service does not. Only the cable coming out, or the camera's supply going away, restarts the processor from flash.

One trap hides in "reboot the machine": a USB port that stays powered in sleep, or an externally powered hub, keeps the camera alive across a host reboot. Cut power at the camera, not at the application.

Test the other causes in order

If the version still reads old after a confirmed power cut, only a few causes remain, and each takes a minute to check.

1. The installed release bundles a different build. Each SDK release ships exactly one firmware image per camera family, which is why firmware and SDK versions move in pairs — the same pairing behind 3D camera header version mismatch: fix firmware and SDK alignment. Open the release notes or the tool's update dialog, which lists the version it will write. If it is not your target, install the release that bundles it: in the case behind this guide, the release carrying 0.2.0.926 rather than the one carrying 0.2.0.951.
2. Another host wrote over your rollback. Any machine that opens the camera with a newer SDK can re-flash its bundled build. Replug with only your host connected and read the version again. If it matches your target, find the other installation and pin it.
3. The write failed midway. A USB drop during the update leaves the tool erroring or the camera off the bus. Run the update once on a short, known-good cable and watch the log end to end. If the camera is now stuck in update mode, follow depth camera stuck in firmware update mode: read the USB ID first.

Worked example: rolling 0.2.0.951 back to 0.2.0.926

Inputs, all from the case that prompted this guide:

• Firmware written earlier: 0.2.0.951, flashed by SDK release v2.35.2, the release that bundles it.
• Target firmware: 0.2.0.926, bundled with SDK release v2.34.0.
• Observation: the v2.34.0 update tool reports complete, and the viewer still lists 0.2.0.951.

The rule: the version readback reports the loaded image, and the loaded image changes only at power-up. A version string reads as four dot-separated numeric fields; here the third field decides.

The arithmetic, field by field: 0 = 0 and 2 = 2 in the first two fields, so the decision falls to the third, where 951 against 926 gives 951 > 926. The camera is still running the newer build. The flash write therefore succeeded and the loaded image never changed — no reinstall would have moved that number.

Apply the power cut from step 5 of the procedure below, then reopen the viewer. The readback now reports 0.2.0.926, equal to the target, so the rollback is complete.

The decision generalises to every rollback:

• readback equals the target → done;
• readback equals the previous build → power never truly dropped, usually a live hub or a sleep-mode port → cut power at the camera and re-read;
• readback equals anything else → a different release did the writing → check which build each installed release bundles and repeat.

The rollback procedure

1. Confirm which release bundles the target firmware, from the release notes or the version listed in the tool's update dialog.
2. Install or launch exactly that SDK release; where the installer allows it, keep releases side by side so you can switch without uninstalling.
3. Disconnect every other host and background service that can open the camera.
4. Run the firmware update and wait for the completion message, not just the progress bar reaching its end.
5. Unplug the camera's USB cable, count five seconds, replug. If the camera is separately powered, remove that supply instead; a host reboot counts only if it cuts power at the port.
6. Reopen the viewer and read the version string. Proceed only when it equals the target.
7. Start your application and log the version again through the SDK API, so the stack you are about to run is verifiably the one you flashed.

When a rollback is genuinely blocked

Cameras are permissive: a build any release ever bundled can normally be written back. Three situations do stop you.

The first is reach. If the target build ships only inside a release that will not install on your operating system, that image is unavailable from that host, and the nearest bundle you can run becomes the realistic target.

The second is device class. PLCs and HMIs police versions harder than cameras: some PLC firmware builds refuse downgrade outright, a limit set per controller family as in this PLC firmware downgrade limit, and an HMI rollback can require a matching host-software version, as with this HMI downgrade and host software compatibility guide. Check the device family's rule before assuming a camera-style rollback applies.

The third is a failed write that left the camera in a bootloader it will not leave. That is recovery, not rollback: start from camera bricked after firmware update: DFU recovery steps that work and the DFU article linked above.

Prevent it: pin versions and read back at startup

Pin one SDK release per workstation and write down which firmware build it bundles. That habit prevents the casual viewer update that re-flashes a bench camera, and the drift where two machines quietly carry different bundles — the same discipline as pinning one library version across a build in Docker build SDK version mismatch: pin one library version everywhere.

Read the firmware version string in your own code at every node start and refuse to run on an unexpected build. The cost of a silent re-flash is wrong behaviour, not an error message, which is what camera firmware version mismatch: fix detection failures safely covers. For planned firmware work across a fleet, run it as a workflow from approval to readback, as set out in camera firmware update workflow from approval to readback.

Bench life has a hardware side too. A replug-heavy routine wears thin consumer cables out, and a marginal cable is how an update write fails midway. Use a short camera cable with a drag-chain-grade jacket; the one below is built for exactly that duty.

If a readback still refuses to move after a true power cut and a confirmed bundle, stop re-flashing and read the tool's log. If you want a second pair of eyes, contact us — free expert support comes with every order. When you are instead choosing cameras for a new cell, the 3D sensors category holds the current range, the accessories finder sorts cabling by length and flex rating, and the system configurator walks a full camera-plus-cabling build. The 3D camera guides pick up everything downstream of the camera.