Camera bricked after firmware update: DFU recovery steps that work

The update looked routine: the IDE said the firmware was old, you accepted, and the write ran to completion. From that point the camera pulses its blue-white status LED in a fast rhythm, the IDE cannot connect, and Windows reports Device Descriptor Request Failed about a minute after every plug-in. It looks bricked. Most of the time it is not: the microcontroller on a board camera carries a DFU bootloader in ROM, written at the factory, and a failed update cannot erase it. The fix is a forced reflash, not a replacement. This guide gives you the decision — dead silicon or broken application image — then the DFU steps, the reflash, and the small set of signs that really do mean the board is finished.

First decision: dead silicon or a broken application image?

Rule first: an update writes the application region of the internal flash and cannot touch the bootloader, which lives in ROM. So any USB activity at all, even a failed descriptor exchange, proves the USB transceiver, the D+ and D- lines and the processor core are alive. What broke is the application image: half-written, or written for a sibling board, so it never starts or comes up with descriptors the host rejects. Windows retries, gives up, and reports Device Descriptor Request Failed.

In the case behind this guide the error landed about 60 s after each plug-in, on every replug, always at the same point. That determinism is the fingerprint of firmware, not of failing hardware. The minute itself is Windows' retry budget, not a camera spec: other hosts and builds report sooner or later, so read the repeat pattern, not the exact second.

A camera that enumerates as the bootloader with no button held is in a harmless cousin of the same state: it is waiting for a firmware file because a BOOT jumper or strap is still closed.

Why the camera loops, most likely cause first

1. Interrupted or mismatched write. The most common cause. The write stopped part-way, through a nudged cable or a hub that dipped its supply, or the file was never meant for this board. Try the IDE's own recovery first: it asks for the board type, erases the internal file system and reloads. In the case behind this guide that recovery ran to completion, even exposed the camera briefly as a USB mass-storage drive, and the loop returned, which points to the next cause.
2. Firmware variant does not match the board revision. An image built for a different sensor or flash layout enumerates cleanly but never brings the camera up, so the IDE finds nothing and offers its bricked-camera dialog. The fix is the variant documented for your exact revision; the hardware revision compatibility check shows how to read the revision before you flash or reorder.
3. BOOT strap left closed. The camera boots into the ROM bootloader on every power-up and looks dead to the IDE. Test: Device Manager lists STM32 BOOTLOADER the moment you plug in, with nothing held. Fix: open the jumper and power-cycle.
4. Electrical failure. Rare after a pure software update, but overvoltage or a static event during handling can kill the USB transceiver. The signature is silence: no device entry, no LED, on every cable and port. That is a different diagnosis, covered by the electrical-death descriptor failure guide.

Force DFU mode and reflash, step by step

What you need:

• The vendor's firmware file for your exact board, in DFU format
• The vendor's DFU utility, or the open-source DFU command-line tool used across the STM32 ecosystem
• A short USB data cable, under 2 m; charge-only cables fail without any error message
• Access to the BOOT button, jumper or header pin, and the board's pinout if the pin sits on a header

1. Unplug the camera. Hold the BOOT button, or fit the BOOT jumper, or tie the BOOT header pin to 3.3 V.
2. Keep it held and plug the camera into a direct port on the PC — no hub, no extension. Release after about two seconds.
3. Open Device Manager and look under USB devices for STM32 BOOTLOADER, VID 0x0483. On a Windows 10 1803 build like the one in this case, map the device to WinUSB with the Zadig tool so a flashing utility can open it.
4. Start the DFU utility and have it list DFU devices. It should report one device: the bootloader, VID 0x0483.
5. Erase the damaged application region, then download the vendor DFU file. Leave the camera alone until the utility reports the transfer verified and complete.
6. Remove the BOOT jumper and power-cycle.
7. Confirm the camera enumerates under its normal name, the LED settles into its normal pattern, and the IDE connects.

Worked example: the one-minute descriptor loop on an STM32F765 board camera

Inputs, each with its source:

• Board: USB board camera on an STM32F765 MCU (from the case)
• Symptom: blue-white status LED pulsing rapidly from plug-in (from the case)
• IDE: vendor IDE 2.0.0, connect attempt gives up after 5 s (from the case)
• Windows: Device Descriptor Request Failed about 60 s after each plug-in, on Windows 10 1803 (from the case)
• Prior recovery: the IDE's erase-and-reload completed and the loop returned (from the case)

Rule, in words: flash writes cannot reach the ROM bootloader, so USB activity of any kind proves the MCU is alive. Firmware fails deterministically, at the same point every cycle, while a marginal cable, port or supply fails at random times or stays silent altogether.

Arithmetic, written out as a reproducibility check. Run three plug-in cycles on three cable-and-port combinations. Cycle 1: error at about 60 s. Cycle 2: 60 s. Cycle 3: 60 s. Total test time 3 x 60 s = 180 s, about three minutes. Spread across cycles: (60 - 60) / 60 = 0%, comfortably inside a ±20% band.

Result: the failure latency reproduces exactly, so the fault sits in the firmware, not in the cable, port or supply. The 5 s IDE timeout fits the same picture: the device enumerates, but with no valid application running, nothing answers the IDE's protocol and the IDE gives up.

Decision, with its threshold: latency reproducible within about ±20% across three cycles means force DFU mode, expect STM32 BOOTLOADER at VID 0x0483, and reflash the vendor DFU image for this board revision, mapping WinUSB first on the 1803 build. A cycle that returns no device at all on a known-good cable and port means stop: the electrical path applies instead.

When the usual answer is wrong

• The DFU device appears, but erase or verify fails at the same flash address on every attempt. One clean retry on a different direct port is worth two minutes. The same address failing twice points at a worn or damaged flash sector, and the board is heading for replacement regardless of firmware.
• No device entry ever appears and the LED stays dark on two known-good cables and ports. That is the electrical-death signature, not this article's fault mode. Follow the supply, cable and transceiver checks in the electrical-death guide linked above, in that order.
• Depth cameras and 3D devices. They run their own update machinery with their own failure modes. The depth camera firmware update by DFU, done safely covers that path, and the USB ID check for a device stuck in update mode tells you which device you actually have before you flash anything.

Keep the next update from looping

• Flash only the variant that matches the board revision, and re-read the revision marking before every field update. The revision check is a two-minute job that prevents this whole class of failure.
• Update from a direct port on a machine that will not sleep mid-write. Bus-powered boards are exposed to supply dips during flash erase, so feed the camera from a stable external supply when the board offers a power input, or at least use the shortest known-good data cable you have.
• Never unplug during erase or write. Wait for the utility to report the transfer verified and complete.
• Archive the DFU file for each board revision, with the revision marking written beside it.

The systems topic page collects the recovery and connectivity guides around this one.

Before you order a replacement: four checks

Work down the list; each check rules out one low-effort cause before any money moves:

• Two known-good data cables, two direct ports, hub removed: watch Device Manager for any entry appearing or disappearing at plug-in.
• BOOT held, or the jumper fitted, at plug-in on both combinations: look for STM32 BOOTLOADER, VID 0x0483.
• One DFU reflash with the correct variant file. If it reports a verify failure, run it once more on a different direct port.
• Status LED dark on every attempt, including through a powered hub.

If all four hold, the board really is finished, and the rebuild is straightforward: match sensor format, lens mount and interface, and the optics and wiring carry over. The replacement guide for an end-of-line camera covers the swap step by step, and the board camera selection guide covers the choice if you are changing family. A C-mount global-shutter USB3 board suits most rebuilt inspection heads, the bare-board option drops into the existing housing, and the GigE option moves the camera off USB entirely. These current boards cover the common rebuild cases.

The card below opens the full board camera category with its finder and configurator.

If the four checks pass and the DFU file for your revision is simply gone, contact us with the board marking and the IDE version, and we will point you at the right file or the right board. To spec a replacement directly, filter sensor, mount and interface in the camera finder and build the chain from the camera step of the configurator.