Camera module dead on every board: prove it is hardware

A camera module that suddenly reports no devices is one of the few faults you can settle with certainty, and without an oscilloscope. The error "No cameras available!" from libcamera-vid --list-cameras means the host never registered the module: the failure happens at enumeration, before streaming, drivers or application settings play any part. The procedure below separates a dead module from a bad cable, host board or OS image — two boards, two images, one known-good camera — and it ends in a decision rather than a suspicion. You then confirm the replacement with a one-command gain check before you blame your streaming application. The steps are written for CSI modules on embedded hosts, and the same logic holds for USB3 and GigE cameras, including the area scan cameras on your line.

What the error tells you, and what it does not

"No cameras available!" is an enumeration failure, not a streaming failure. At boot — or at plug-in for USB — the host probes the module on its control bus, reads its identity and publishes a device the camera stack can open. Break that chain anywhere, at power, connector, control bus or module, and the stack prints the same one-line error. The message names the layer, not the part; the matrix is the instrument that names the part.

Two different faults share this message. If the kernel logs the sensor but the stack still lists no device, software owns the problem — overlays, permissions, stack configuration — and that case is covered in kernel detects the sensor but libcamera lists no camera device. This article handles the other case, where nothing registers anywhere. One observation shifts the odds before you start: a module that worked yesterday and died with no configuration change on your side is already pointing at hardware. Suspect software only while an image change coincides with the failure.

Likely causes, in order of probability

1. The connection — most common. A ribbon that is not fully home, a latch not flipped, contacts torn or contaminated, or a cable fatigued from flexing. Threads on this error again and again end at a re-seat or a cable swap; a loose connector between module and board has been the entire fault in more than one case. Test: power down, re-seat both ends, then substitute a known-good camera cable. Cost: ten minutes.
2. The OS image or camera-stack configuration. An update can drop the module's device-tree overlay or change the stack, so a healthy module stops registering. Test: boot an older image the module worked on, unchanged. If the module appears there, fix the overlay and keep the camera.
3. The module. A failed regulator, a dead control interface or a cracked flex on the module's own board stops enumeration on every host. This is the fault the matrix proves.
4. The host board — least likely. A damaged camera connector or a bad rail on one host. Two independent hosts failing identically at the same time is the least probable hypothesis on the bench, so the board is cleared last, and cleared with a known-good camera rather than with more swaps of the suspect module.

The isolation matrix: two boards, two images, one known-good camera

Run the tests in order and write every result down; a row only counts if it changes one thing.

1. Power down. Re-seat the ribbon at both ends and confirm the latch orientation. Boot, run the listing command, record the result.
2. Substitute a known-good ribbon cable. Record.
3. Boot the older image the module previously worked on. Record.
4. Move module and cable to a second host board of the same type, same image. Record.
5. Try a third host of a different type, one where this module had worked before. Record.
6. Fit a known-good camera to the original board and image. If it enumerates and streams, stop: order a replacement module.

If the module maker provides a diagnostic or bug-report tool, run it once per image and keep the output with your rows; it snapshots the software state in one file.

Read the table as set arithmetic. The suspect module is present in four failing rows — two boards times two images is four combinations — and absent from the single passing row. Changing the board with the image held constant (rows 1 and 4) clears the boards; changing the image with the board held constant (rows 1 and 3) clears the images; row 6 clears the board-and-image pair outright; step 2 cleared the cable by substitution. The only component present in every failure and absent from every success is the module.

On CSI hosts the camera overlay is sensor-specific. If your known-good camera uses a different sensor, enable its overlay first; the test still proves the host's connector and power path.

The decision: replace the module

When your table matches the one above, replace the module. No overlay, driver or application change brings back hardware that fails enumeration in four independent combinations while a known-good camera streams on the same setup. The evidence is as strong as bench isolation gets: two boards of the same type plus a different host, two OS images including one the module had worked on, a substituted cable, and a passing control camera. Fit the replacement to the original board and image first — the strictest combination — then run it across the other rows you recorded. A replacement that enumerates on every image and host closes the proof: the fault never was in the images.

Check gain control at the sensor before blaming the application

After a replacement streams, the next complaint is usually that gain or brightness settings in the streaming application do nothing. Test the sensor first, with one tool and two captures of the same fixed scene:

rpicam-still -t 0 --gain 1
rpicam-still -t 0 --gain 4

Lock the exposure to a fixed time before you capture. With auto-exposure running, the loop cancels a gain increase by shortening the exposure, so the mean barely moves — which looks exactly like a dead control and is the usual reason a gain setting "does not work". Analog gain scales the signal roughly linearly below saturation:

Worked example: with exposure locked, the scene reads a mean of 42 DN at gain 1. At gain 2 expect 42 × 2 / 1 = 84 DN; at gain 4 expect 42 × 4 / 1 = 168 DN. Values cap at 255 on an 8-bit capture, so keep the highlights below saturation or the comparison reads low. Noise rises with gain too — the multiplier lifts noise as well as signal — which is why you compare means, not noise.

The decision: if the mean scales with gain, the sensor and its control path are healthy, and the parameter is being dropped in the application layer, in how your streaming software passes camera options to the stack. If the mean does not move with exposure locked, the fault sits below the application — control path, driver or module — and the matrix starts again at step 1. If your test code crashes along the way, isolate the vision code from the hardware before you draw conclusions from it.

When the matrix blames the module and is wrong

Four mistakes make a healthy module look dead everywhere:

• The ribbon travelled with the module. If the same cable goes wherever the module goes, the fault follows the pair, not the part. Substitute the cable as its own variable — step 2 exists for this. Latch and contact damage are the classic culprits, and the handling limits are in ribbon cable latch and length limits. The cable-first rule is identical on standard interfaces: check the cable before you swap hardware.
• The storage card travelled with the module. A system card carries its camera configuration with it, so two images on one card can share the same broken overlay — one software configuration tested twice. Install the second image fresh, or run it on a host whose configuration lives on separate storage.
• Both images updated from the same source. If both images pull the same camera-stack version, they are one witness, not two. Confirm the stack version differs between your images before you count rows 3 and 5 as independent.
• One power path. A damaged supply or powered hub that moves with the set starves every combination the same way. Run the final row from a different supply.

The mirror case also exists: if the known-good camera fails on the original board too, the board is implicated — inspect its connector before you fit the next module, because a damaged host connector is also how modules die. For failures in the field that are repeatable and unit-specific, the same discipline applies: camera fault isolation for repeatable, unit-specific failures.

Choosing the replacement

Two routes, and the choice is about the host, not the image.

Like-for-like CSI module: the fastest restore, because the configuration on your card already enumerates that sensor. Match the part to the host's supported sensor list before ordering — board level camera sensor compatibility — and check hardware revision compatibility before you reorder, because production lines change.

A board-level camera on USB3 or GigE: a standard-interface module enumerates on almost any host without a device-tree entry, so the camera survives host swaps and OS reinstalls. From our board-level cameras:

The LS-BCM-0003 is a 3.1 MP USB3 board-level camera with a 1/1.8" global-shutter sensor, a C-mount and a 120 fps frame rate — global shutter is the one to pick when the part or the camera moves. The LS-BCM-0020 is a 6.3 MP GigE board-level camera with a 1/1.8" rolling-shutter sensor, a CS-mount and an 18 fps frame rate, and GigE gives you longer cable runs than USB3. The MV-CB060-10UM-B is a 6 MP USB3 board camera supplied as a bare board with a 1/1.8" sensor, for building straight into a fixture. A USB3 module needs the right lead as well; the LS-CBL-0219 is a 3 m USB3.0 camera cable in high-flex drag-chain construction.

If you go board-level with your own carrier, match the board-level camera and USB3 bridge board before you stream. For lenses, the mount decides the menu — see board camera lens mount thread sizes — and if the failed module's sensor is being phased out, plan the swap with board level camera replacement when a sensor goes end of line.

Checks before you order

• Interface your host enumerates without custom configuration: USB3 and GigE on almost any host; CSI only with an overlay for that sensor.
• Mount: C, CS or M12, matched to the lenses you already own.
• Shutter: global for motion on the line; rolling where resolution matters more and the scene is static.
• Sensor format inside your lens's image circle.
• Lifecycle: a model flagged end of life soon will put you back here sooner than you want.

Prevention on the bench

• Keep one known-good camera per interface on the bench. It is the reference standard the whole matrix depends on, and it converts a day of doubt into half a day of rows.
• Strain-relieve every ribbon so it does not flex at the connector. Fatigue at the latch is the most common cable failure and the most common false verdict of a dead module.
• Handle modules grounded and store them shielded. The control interface that enumeration depends on is also the part that static damage takes out first.

When you know what you need, the camera finder filters by interface, mount and shutter, and the configurator walks the same choices step by step. The cameras topic page gathers the rest in one place. For a specific replacement question, use the contact page — expert support is free with every order, and in-stock items ship within one business day.