A host that reports your camera as detected and then receives no frames looks like a contradiction, and it eats bench hours. The two behaviours run on separate wiring: a slow control probe that tolerates a marginal connection, and high-speed data lanes that do not. This guide is for anyone bringing up a board-level camera on an embedded host, and for anyone rebuilding a machine after its camera link died. You get the reason the split exists, the causes ranked in bench order, a test and a fix for each, one worked example that shows why detection proves nothing about the data path, and the decision rule for when to replace the flex, the module or the whole link.
Why a camera can be detected and still send nothing
A camera socket carries two wiring systems that share nothing but the connector. The control link is I2C: the host writes a register address and reads back a chip ID, a transaction of a few dozen bits at 100 kbit/s standard mode or 400 kbit/s fast mode. When a host reports the camera detected, that is all it means: one register answered one probe. Nothing in the image path has been exercised.
The image path is separate: MIPI CSI-2 lanes with sub-nanosecond edges, clocked in embedded cameras at roughly 400 Mbit/s to 1.5 Gbit/s per lane, on two or four lanes. CSI-2 spreads every packet across all enabled lanes at the byte level, so the receiver completes a packet only when every lane delivers its share. One dead lane, one open contact or one reversed pair leaves no packet complete, and the capture times out with no data instead of a degraded image.
That asymmetry is the diagnosis. A contact that probes cleanly at 400 kbit/s can fail completely at several hundred megabits per second, and the fast lane drivers are the first thing static, heat and hot-plug transients kill. The same split exists on cable links: a GigE camera can answer discovery while its stream dies on a packet-size setting, which our bridge bandwidth guide covers for USB. The article on separating I2C detection from MIPI frame timeouts handles the case where detection itself fails; this one picks up where detection succeeds and frames never start.
Likely causes, ranked
Work the rows top to bottom; the first three settle most bench cases. Every row assumes the same symptom: the host reports the camera detected and the capture returns no data.
| # | Cause | Why detection still passes | Test | Fix |
|---|---|---|---|---|
| 1 | Flex not seated or latch open at either end | On a partially inserted flex the control pair makes contact before the lanes do | Reseat both ends, close both latches, power-cycle | Correct seating |
| 2 | Flex reversed | The ID probe can still answer while the lane contacts float | Compare contact side against the host silkscreen at both ends | Flip the flex |
| 3 | Module seated in the display socket | The sockets share a footprint, and enough pins land live for the probe to answer | Match the printed socket marking, not the mechanical fit | Move to the camera socket, then cross-test the module |
| 4 | Damaged flex: crease, kink, tarnished contacts | A slow probe pushes through contact resistance that destroys lane edges | Inspect under bright light, then swap a known-good flex | Replace the flex |
| 5 | Host lane count or pixel format mismatch | The probe never consults the lane configuration | Set lane count and format (RAW10/RAW8) to the module's actual values | Apply, power-cycle, re-capture |
| 6 | Supply sag when streaming starts | The probe draw is tiny; the first frames load the rail | Measure the rail at the module while capture starts | Fix the supply or its wiring |
| 7 | Lane-driver damage from a hot-plug, wrong socket or ESD | The I2C block survives what the fast drivers do not | Suspect module on a second host with a known-good flex | Replace the module |
Rows 1 to 4 are the physical data path, row 5 is configuration, rows 6 and 7 are electrical. The expensive mistakes come from skipping rows 1 to 3, which cost nothing to check.
Tests in order
-
Prove the detection message is live. Unplug the module completely and run detection again. If the host now reports the camera missing, the probe genuinely reaches the sensor; if the message does not change, the host is reading a stale result and the fault may sit upstream of the camera entirely.
-
Reseat both connectors. Withdraw the flex at the host socket and at the small socket on the module itself, reinsert to full depth and close each latch. Power-cycle, then capture. Half-seated flexes are the most common finding on the bench.
-
Check orientation at both ends. The contact side is marked in the host silkscreen and on the module board. A flex that fits can still be mirrored, and a mirrored flex keeps the probe alive on some modules while the lanes see nothing.
-
Confirm the socket. Where camera and display sockets share a footprint, match the printed marking, not the fit. If the module has ever sat in the display socket, treat it as suspect even after you move it, and let the cross-swap in step 8 clear it.
-
Inspect and swap the flex. Look for crease lines across the conductors and dull contacts, then run a known-good flex of the same type. Replace outright if you can see a crease: a creased conductor becomes an intermittent that reseating never fixes.
-
Match the host's lane and format settings. A two-lane module wired into a four-lane endpoint streams nothing. Set the lane count and pixel format (RAW10 is the usual raw format) to the module's actual values and re-capture. Our article on two-lane versus four-lane mode shows how the lane mode also changes what the probe reports.
-
Watch the supply during stream start. Detection draws almost nothing; the first frames load the rail. Measure the supply at the module while capture starts: a sag of a few hundred millivolts at that moment is the fault, and our power, clock and device-tree checks take it from there.
-
Cross-swap. Run the suspect module on a second, working host with a known-good flex, and a known-good module on this host with the suspect flex. Module silent everywhere: replace the module. Module works here with a different flex: replace the flex. Every module silent in this one socket: suspect the host board or its settings, not the cameras.
Worked example: 2592 × 1944 raw frames on a two-lane link
This is the arithmetic behind the decision rule, for the 5 MP capture that fails in the bench case behind this guide. Inputs: width 2592 pixels and height 1944 pixels (the failing capture's own settings); RAW10, 10 bits per pixel (the standard CSI-2 raw format for such sensors); 15 frames per second (an illustrative stream rate; the rates scale linearly, so 30 fps doubles them); two data lanes (the common count at this resolution); and the control probe, a two-byte ID read of about 40 bits on the wire at 400 kHz.
Frame size: 2592 × 1944 × 10 bit = 50,388,480 bit ≈ 50.4 Mbit, or 6.3 MB, per frame. Payload rate: 50.4 Mbit × 15 = 756 Mbit/s. Across two lanes that is 378 Mbit/s per lane of payload, and roughly 400-500 Mbit/s on the wire once packet overhead and blanking compress the active time. The probe: 40 bit ÷ 400,000 bit/s = 0.1 ms.
The ratio is the point: 756 Mbit/s ÷ 0.4 Mbit/s ≈ 1,900. The image link runs at nearly two thousand times the bit rate of the link that reported detection, so a connection that probes cleanly says nothing about the lanes.
Decision, with its threshold: a camera that reports detected and returns no frames is a data-path fault until a known-good flex and a known-good module have both failed in the same socket. The probe you pass sits three orders of magnitude below the capture you are waiting for. Scale the numbers for your own sensor with the camera resolution calculator:
When the usual answer is wrong
Four findings point away from the data path:
- Detection itself fails. The fault is then on the control side: I2C address, pull-ups, power or a dead control block. Start with our article on diagnosing the wrong I2C probe.
- Frames arrive but are torn, striped or corrupted. The lanes work; the format or wiring is mismatched, which is a different fault with a different fix — see isolating a corrupted camera image.
- A control-callback error word appears after an update. Some host stacks print a word such as 0x4f525245 when the camera stack and the kernel have drifted apart; the same bench case produced it after firmware updates. Bring the host's camera stack current before you condemn any hardware.
- Everything physical checks out. Work upstream: the camera-enable setting in the host's boot configuration, then the power and clock gates feeding the camera block. Our article on isolating the failing startup stage walks that sequence.
Keep it from coming back
- Power down before you touch the flex. The control pair survives hot-plug transients that the lane drivers do not.
- Close both latches every time, and reseat after transport or vibration before debugging software.
- Use the flex the socket was designed for. A display flex with the same footprint is not a camera flex, whatever it looks like.
- Handle bare modules by the edges on a grounded surface; the fast lane drivers are the first thing a discharge kills.
- Route the flex with a gentle curve and real strain relief. A crease across the conductors is a future intermittent that reseating will never fix.
- Keep one known-good flex and one known-good module on the bench. Every test above collapses without them.
Replace or rebuild: the decision
Replace the flex when it is creased, tarnished or fails the cross-swap, using the exact type and length the socket expects; our ribbon-cable guide gives the latch and length limits. Replace the module when it stays silent on a second host with a known-good flex. Suspect the host board when every module is silent in one socket.
If the flex keeps dying, or the next project gives you the choice, move the image path off the bare flex and onto a cable. A board camera on USB3 or GigE connects through a cable with a real latch or screw locks, which removes the seating failure class entirely:
The board cameras pair with matching cables: the LS-BCM-0003 is a 3.1 MP USB3 camera with a C-mount, and the LS-CBL-0219 is a 3 m high-flex USB3.0 camera cable; the LS-BCM-0020 is a 6.3 MP GigE camera with a CS-mount, and the LS-CBL-0199 is a 3 m high-flex GigE camera cable with screw locks.
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Sensor format
- 1/1.8"
- Lens mount
- CS-mount
For a camera mounted metres from the host, the LS-CBL-0117 is a 15 m RJ45 camera data cable with a locking stud; the camera data cables cover the other lengths and connectors.
- Type
- Camera data cables
- Length
- 15 m
Pick the replacement with the camera finder or step through the camera configurator if you are rebuilding a whole station; the accessories finder lists the cables. If you want a person to check the match between your host and the camera, contact us: expert support is free with every order. More bring-up and debugging guides sit on the systems topic page.
Questions
Can a camera pass detection with a reversed flex cable?
Sometimes. The detection probe reads one ID register through the control pair, and a partially or wrongly seated flex can still make that pair's contacts while the lane contacts float. Treat any seating doubt as a data-path fault: reseat with both latches fully closed, and trust a detection message only after you have watched the host report the camera missing with the module unplugged.
Does a camera cable fit the display connector on the same board?
On many boards, yes physically, and that is the trap: camera and display sockets share a footprint and a latch, but the lanes are wired differently. A module can still answer detection from the wrong socket while its data lanes land on wiring they were never meant to see. Move the cable to the socket marked for the camera, then clear the module with a cross-swap on another board.
What bit rates do the two camera links actually run?
The control probe is I2C: 100 kbit/s in standard mode, 400 kbit/s in fast mode. The image lanes are MIPI CSI-2 over a D-PHY physical layer, from about 80 Mbit/s to 2.5 Gbit/s per lane across the standard's generations; embedded camera modules typically clock 400 Mbit/s to 1.5 Gbit/s per lane, on two or four lanes. The gap between the link that reports detection and the link that carries frames is therefore a factor of a thousand to ten thousand in bit rate.
Why does one dead lane stop all frames rather than lowering the frame rate?
Because CSI-2 has no per-lane fallback: if one lane never leaves its low-power state, no packet ever assembles at the receiver, and the capture layer sees an incomplete stream and discards it. The usual behaviour is all or nothing, not a halved frame rate, so a lane fault presents exactly like a seating fault.
When do I replace the module instead of the flex?
After the cross-swap. A module that stays silent everywhere with good flexes is dead, usually from lane-driver damage after a hot-plug, a wrong-socket session or a discharge, and replacement is the only repair. A flex that kills good modules on other hosts is a bad flex; a socket that silences every module points at the host board instead.