New camera module not detected: check the firmware version first

You fit a new image-sensor module to a compact vision board, run the vendor's example, and the tool answers with "Failed to detect the image sensor or image sensor is detached". The camera the board shipped with still enumerates every time you swap it back, so the connector and cable look innocent — and in this failure class they usually are. The gate is the board's runtime firmware: a module released after your board was flashed only enumerates from a minimum firmware version, and an older runtime rejects it before any electrical test runs. This walkthrough gives you the check order, the update procedure with its awkward start, and the tests that prove the module itself is fine.

The symptom that points at firmware

The error text says the sensor is detached, which sends everyone to the connector first. The signature that points elsewhere is symmetry: the original camera detects on every refit, the new module fails on every seat, across several reseats. A contact fault is random — it changes with pressure, orientation and cable flex. A version gate is deterministic per module: same board, same cable, same seat, same refusal. That determinism is the fastest diagnostic on the bench, and it costs one swap.

Read the firmware version before the connector

The number lives in your tooling. On scriptable vision boards of this class it prints on the status bar of the IDE while the board is connected; in vendor tools for industrial cameras it sits in a device info panel, under a label like "Firmware Version" or "Software Version". Capture it with a screenshot before anything else.

Then find the module's minimum, stated on the module's product page or in its release notes. In the case behind this guide, the board reported 4.5.1 and the module needed the current runtime, 4.7.0:

Version numbers compare field by field from the left: majors tie, then 5 loses to 7. No number of reseats turns 4.5.1 into 4.7.0, so once this comparison fails, stop debugging hardware and run the update. On single-board computers the same discipline holds: ask the platform whether it sees the camera through its own reporting command instead of guessing from a desktop tool — the routine is shown in checking camera detection from the command line.

Likely causes, in the order to test them

Ranks 2 and 3 are the wiring side, covered in detail in image sensor not detected: check camera module connections. Rank 4 is the host mirror of rank 1: an old SDK refuses a new device exactly as old firmware refuses a new module — the ordering test is in depth camera not detected: check the SDK version before the cable, and on GigE cameras the symptom is a parameter read failure, as in GigE camera failed to read parameter. For USB cameras the port-and-cable ladder is the same; work through USB connection checks for an undetected camera.

Keep one known-good cable on the bench for the rank 3 swap test. The LS-CBL-0219 is a 3 m USB3.0 camera cable in high-flex drag-chain grade.

The fix: update the board firmware

The update runs from the vendor's own tool, and the board enters it through a bootloader jumper. Plan it as a quiet fifteen minutes, not a between-tasks moment.

1. Record your current camera settings — exposure, gain, region of interest. An update can reset them, and motion or detection settings with them.
2. Get the hardware the procedure names, in this case a jumper wire.
3. Power the board down, fit the jumper to select bootloader mode, reconnect, and start the updater.
4. Expect the transfer to start the instant you press ok. If the tool instead sits on its waiting stage — the one that offers ctrl c to cancel — cancel and start again: making and remaking the jumper contact can take a few attempts before the board sees it.
5. Let the write finish completely.
6. Reboot, then read the version again in the same place as before. It must show the target, 4.7.0 in this case, not 4.5.1.
7. Refit the module and run the vendor's example; confirm a live frame.
8. Re-apply the settings from step 1 and re-check image quality on a known target.

Why a version gate exists at all

The runtime holds a table of modules it knows how to bring up: the identity query, the power and clock sequence, the driver. A module launched after your board was built is simply absent from an older table, so enumeration fails before the hardware is questioned — the message about a detached sensor is the runtime's only way of saying that nothing it recognizes answered. Linux does the same one level down: a camera-sensor driver binds only the modules listed in its module table, and supporting a new sensor means adding the entry and shipping a newer kernel. Machine-vision cameras repeat the pattern on the host side, where the readable version registers are described in accessing GigE camera registers at runtime. For a deeper treatment of version-pair failures, see camera firmware version mismatch: fix detection failures safely.

When the schedule cannot absorb the round-trip

If a firmware update window is days away, inspect with a camera whose sensor was matched to its board at the factory. A board-level camera arrives as one tested assembly, so the not-in-the-table failure class cannot occur; you trade the freedom to swap sensors for detection you do not have to argue with.

The LS-BCM-0003 is a 3.1 MP board-level camera with a 1/1.8" global-shutter sensor, a C-mount and a USB3 interface at 120 fps.

The MV-CB060-10UM-B is a 6 MP USB3 camera supplied as a bare board with no lens mount, on the IMX178.

If you build a bare board into your own carrier, match it to its bridge before streaming — the pairing rules are in board-level camera and USB3 bridge board: match before you stream. To spec a replacement in one pass, start at the camera step of the configurator.

Checks before you order a second module

• Write down the reported firmware version and the module's stated minimum. If the product page omits the minimum, ask for it before ordering — one question beats a dead bench day.
• Confirm the module generation is the one your board revision supports, per board-level camera hardware revision compatibility.
• Check connector orientation once against the pinout drawing, as covered in MIPI CSI camera connector pinout.
• Run the swap test with the original camera: a deterministic pass on the old camera and a deterministic fail on the new one, with versions matched, is your evidence for a warranty claim.
• For a structured pass over the whole bench set-up, use the board camera evaluation checklist.

When the firmware answer is wrong

Three outcomes break the pattern. First, the version now meets the minimum and the module still refuses: the fault is physical, and the connector and wiring checks from the causes table are the next move. Second, the module is detected in the vendor's tool but not in your own code: that is host permissions, not firmware — see USB3 Vision camera works as root only. Third, the module works after the update but the image is off: a blue cast on a colour stream points at ISP calibration rather than detection, as in blue tint on a board camera.

If the comparison and these branches still leave you stuck, send the board line, the module and both version numbers through the contact page and we will confirm the minimum before you order anything else.