Sensor detected but frames time out: separating I2C from MIPI failures

A sensor that answers every I2C read but never delivers a frame is one of the most misleading failures in embedded vision. The probe log looks clean, the device node appears in the list, and then every capture dies on the same timeout. The combination is not ambiguous, though: it splits the fault tree in half before you touch a single setting. The control path (I2C) and the data path (MIPI CSI-2 lanes) are physically separate, so a healthy detection proves nothing about frame delivery. This guide gives you the disconnected-sensor test that confirms which half you are in, the causes ranked by how often each is the answer, the bandwidth arithmetic that rules one out in a minute, and the point at which switching the interface beats debugging the platform.

What a clean sensor detection proves

Detection and streaming run on two different physical buses, and only one of them has to work for the device list to look healthy.

The I2C control bus is a slow two-wire connection. At start-up the driver talks to the sensor over it: it reads the ID register to confirm the part, then programs mode, resolution and exposure. A successful probe proves the sensor has power, has its input clock, sits at the expected address and matches the driver. That is all it proves.

Frames travel on the MIPI CSI-2 data path: a clock lane plus one or more differential data pairs, each running hundreds of megabits per second, packetised and checked by the CSI receiver in front of the ISP. The receiver fills buffers from that stream and hands them to your application. When no buffer fills within the dequeue timeout — 1 second by default in these stacks — the capture aborts with a device timeout and the pipeline restarts.

Read the symptom precisely. Sensor detected plus frames time out means the control path is proven and the data path is delivering nothing. You are not debugging register settings; you are debugging the lanes. If detection itself fails — no device node at all — that is a different fault tree, and the device-tree chain that gets a sensor to probe is where that case starts.

The disconnected-sensor test that splits the fault tree

This test takes a minute and decides everything after it.

1. Start a capture and note the exact timeout line, including how often it repeats.
2. Power down, unplug the ribbon at the sensor end, power up and run the identical capture command.
3. Compare the two runs.

If the signature is identical — same error, same interval, sensor in or out — the receiver never saw lane activity at all. The stream is not slow, marginal or misformatted; it is absent. No exposure value, format negotiation or register write can cause that. The causes are physical (connector, cable, module) or platform-level (overlay lane mapping, driver support).

If the two runs differ — short frames, torn frames or a different error with the sensor connected — the lanes are toggling and the fault is signal integrity or format handling, not absence of data.

One subtlety worth naming: the dequeue timer does not care whether the sensor is present, so these stacks fail a capture politely at the same timeout even with nothing attached. That is exactly the diagnostic value. A timeout that ignores the sensor is a receiver-side or platform-side fault, and it tells you to stop adjusting sensor settings immediately.

The causes, ranked by how often they are the answer

The ranking below runs from the cause that most often survives scrutiny to the least likely, with a test and a fix for each:

Causes 1 to 3 are platform-side, and the power, clock and device-tree walkthrough covers that side step by step. The lane-count assumption has its own failure mode: the two-lane versus four-lane mismatch usually bites at probe, but a hand-edited overlay can pass probe and still deliver no frames, so check the lane number twice.

Rule bandwidth in or out with one calculation

Before spending an evening on signal integrity, spend a minute on arithmetic. A data path that is too slow does not produce clean repeating timeouts; it produces FIFO overflow errors and truncated frames. Run the numbers once, and you can answer the bandwidth question before anyone asks it:

The 0.8 factor is a planning estimate for D-PHY packet overhead: headers, packet framing and blanking mean the wire never carries payload on every cycle.

Worked example, with illustrative inputs: a 1280 × 800 mono sensor, 8 bit, 60 fps, on two data lanes.

• 1280 × 800 = 1,024,000 pixels per frame
• 1,024,000 × 60 fps = 61,440,000 pixels per second
• 61,440,000 × 8 bit = 491,520,000 bit/s of payload, about 0.49 Gbit/s
• ÷ 2 lanes = 245.76 Mbit/s of payload per lane
• ÷ 0.8 ≈ 307 Mbit/s of wire rate per lane

That sits far below the roughly 800 Mbit/s per lane where a D-PHY link commonly tops out, so two lanes carry this stream with room to spare. The fuller treatment is in the MIPI lane bandwidth guide.

Read the result as a verdict, not just a number. A stream this small cannot saturate a healthy two-lane link, so if capture still times out, the link is not slow — it is silent. When bandwidth genuinely is the problem, it shows up as a lane FIFO overflow with the sensor otherwise healthy, never as a 1-second timeout repeating unchanged.

The fix order that converges

Work these in order; each step takes minutes, and a hit at step 2 can invalidate steps 3 to 5.

1. Platform. Confirm the OS release is one the camera stack supports for the board. An unsupported stack produces exactly the symptom described above: clean probe, opaque stream-on failure.
2. Stock overlay. Run the overlay that ships with the current kernel. If a boot configuration line forces an overlay from an earlier project, remove it and test the stock one first.

3. Lane and port arguments. Set the overlay's data-lane count to the module's actual lanes and its port argument to the connector in use — boards with two CSI inputs take a port argument, cam0 and cam1 in the capture logs. Re-run the disconnected test after any overlay change; a correct configuration changes or removes the timeout.
4. Raw capture. List the video nodes with v4l2-ctl --list-devices: the CSI receiver and the ISP each expose their own set. Grab raw frames at the receiver's node, bypassing the ISP. What raw output means is its own subject — the raw sensor output explainer covers it.

5. Physical. Reseat under the clamps at both ends, check contact orientation, swap to the shortest cable available, then swap modules. Two modules and two cables failing identically on both ports is not bad luck; it is a platform cause you have not reached yet.

When switching the interface beats debugging the platform

Set a stop condition before you start, because CSI bring-up can absorb weeks. A workable one: if the sensor probes cleanly, the disconnected test shows identical timeouts, and the ranked causes are exhausted with two modules, two cables and both ports, the remaining fault lives in driver or overlay support for that sensor on that board — open-ended work that is not yours to schedule. On a one-off rig or a short production run, change the interface instead of the platform.

A USB3 or GigE board-level camera sidesteps this fault tree. There is no overlay, no lane mapping and no ISP bring-up: the camera enumerates as a standard device and exposes its controls through the normal API. What you trade away is register-level access to the bare sensor inside your own pipeline; what you gain is a bring-up measured in minutes.

For the USB3 route, the LS-BCM-0003 is a 3.1 MP USB3 board-level camera on an IMX252 sensor, 1/1.8" format, global shutter, at 120 fps.

For distance from the host and standard industrial cabling, GigE suits better: the MV-CB016-10GM-M-W pairs a 1.6 MP mono IMX296 sensor, global shutter, 1/2.9" format, with a GigE port on an M12 mount.

Browse the board-level camera range, filter by interface, sensor format and shutter in the camera finder, or walk the whole chain from the camera configurator. The interface trade-offs by cable length, bandwidth and host support are laid out in board level camera selection for embedded vision machines.

Prevent the next one: qualify before you build

The control-versus-data split applies across interfaces. On a GigE area scan camera, a capture timeout with clean enumeration points at the network path rather than the camera, and the same triage habit applies:

• Acceptance is one captured frame on the current OS, not a clean probe line. A probe proves the control bus only.
• Pin versions: kernel, camera stack and overlay files, recorded with the project, so an update cannot silently change lane behaviour.
• Keep reference hardware: one known-good module and one short ribbon, reserved and never modified.
• Write the disconnected-sensor run into bring-up documents as step one of data-path triage.
• Size lane bandwidth with the formula at design time and leave about 2× headroom, so a later frame-rate bump does not become a signal-integrity project.

More systems-side debugging lives on the systems topic page, and the evaluation discipline in checklist form is the board camera evaluation checklist.