MIPI sensor detected but streaming fails: power, clocks, device tree

Detection logs look like success: the driver binds the sensor, the video node appears, your pipeline starts — then stream-on fails with an I2C no-acknowledge and not one frame. If you are bringing a MIPI CSI-2 sensor up on a custom or modified carrier board, you will rank the causes in the order they occur, confirm the failure with two standard commands, check power rails, the sensor clock and the CSI device tree mapping with real numbers, and decide when a standard-interface board camera is the better choice.

Why does the sensor probe cleanly and then fail only at stream-on?

Because probe and stream-on exercise different hardware. Probe only needs the sensor's I2C interface alive once; stream-on needs every power rail, the master clock, the CSI lanes and the receiver configured, and any one of those can be missing.

Probe and bind prove the driver matched the compatible string and that the I2C controller reached a device once at boot. Streaming proves the rails, the clock, the lanes, the receiver configuration and the sensor configuration at the same moment. That is why a board can pass detection all morning and never deliver a frame. On custom carriers the stream-on failures rank in a stable order:

A sensor that never produced a video node at all fails one stage earlier; that case is covered in Sensor probes but no video node: fix the devicetree chain. This article starts where that one ends: the node exists, the frames do not.

How do you confirm the failure before changing configuration?

Confirm it with two commands. The media controller shows whether the pipeline is linked, and a raw V4L2 capture with a small frame count reproduces the failure without your application; if it blocks for a couple of seconds and the kernel logs a timeout, the sensor is not delivering frames.

sudo media-ctl -p -d /dev/media0

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

The topology dump answers three questions before any capture: the sensor entity's pad prints the format it will output, and both links — sensor to CSI receiver, receiver to capture node — must read as enabled. If your stack offers no control named bypass_mode, drop it from the command; everything else is standard V4L2.

A healthy run prints frame counters at once. A broken one blocks briefly and the kernel log names the stage: an I2C error sends you to power and clocks, a capture timeout with clean I2C sends you to lane mapping, and receiver errors point at format and rate. Save dmesg from before and after each attempt — it is the evidence trail for every later change.

Which power rails and clocks must be enabled at stream-on?

All of them, in order: the analog, digital-core and interface rails the sensor node declares, then the master clock, then reset release. A typical small CMOS sensor runs three rails — 2.8 to 3.3 V analog, 1.1 to 1.5 V core, 1.8 V I/O — plus a 24 or 27 MHz clock.

Those voltages are typical for this sensor class; the data sheet of the part you mounted is the authority for its values. The sequence is fixed: rails stable, clock running, reset released, and only then does the I2C interface acknowledge. A sensor without its clock looks on the bus exactly like one without power.

The custom-carrier failure is specific: the rails exist on the schematic but never entered the sensor node's supply list, so the driver enables nothing at stream-on even though boot firmware powered them once. Measure each rail while a stream attempt is in flight, not afterwards, because many stacks power the sensor down between attempts. If a rail sits at zero, trace its enable: a regulator whose enable pin routes differently on your board than on the reference shows up on a meter in one minute.

Why does I2C answer at probe but no-ack at stream-on?

Because the driver powers the sensor down between probe and your first capture. Probe runs on boot-time power; at stream-on the driver re-enables only the supplies it knows about. If one supply or its enable GPIO is missing from the sensor node, the sensor goes silent.

Read the log line as data: the value after 'no acknowledge from' is the 7-bit I2C address the driver tried, and silence means nothing on the bus answered. Detection proved that address was right once, so a repeat no-ack at the same address points at power or clock delivery, not addressing. The full isolation procedure for this symptom is in Camera I2C communication failure: diagnose sensor probe errors.

One case is not a fault: with two cameras fitted, the driver probes a channel's default address before the one you actually wired, so a single no-ack line is expected when a node still carries the reference camera's address. Put each module's real address in its node — the MIPI camera sensor ID mismatch guide shows how the wrong-address probe reads in the log.

Which device tree CSI settings leave the capture waiting forever?

Two properties decide it: port-index selects which receiver input your lanes are physically wired to, and bus-width declares how many data lanes both sides will use. If either names hardware that is not there, the receiver sees no data and the capture times out.

The channel chain runs sensor endpoint, CSI channel endpoints, capture port, and it must agree end to end. A four-lane module wired to receiver input 2 carries these two properties at both endpoints of its channel:

port-index = <2>;
bus-width  = <4>;

The two remote-endpoint phandles must also reference each other, and the channel count must cover every fitted camera. Walk the schematic rather than the source: trace the clock pair and the data lanes D0 to D3 from the connector to the receiver, read the input number off the reference design, then set port-index to match. bus-width must equal the number of data lanes the module transmits on; declaring two lanes for a four-lane module starves the receiver exactly as a broken trace does. The declared pixel clock belongs in the same check — the timing the driver programs must be the timing the receiver was told to expect. The mapping failure modes are set out in Camera device tree overlay CSI mapping troubleshooting.

Is your lane count enough for the format you set?

Do the arithmetic before blaming hardware: 1920 × 1080 pixels at 10 bits and 30 fps is 622 Mbit/s of payload; with CSI-2 packet overhead, four lanes carry about 179 Mbit/s each — comfortable — while two lanes must run 358 Mbit/s each.

Worked example, 1920 × 1080 at 10 bits and 30 fps: 1920 × 1080 = 2,073,600 pixels per frame; × 30 = 62,208,000 pixels per second; × 10 bit = 622 Mbit/s of payload. CSI-2 packet framing adds roughly 10 to 20 percent; plan on 15 percent, so 622 × 1.15 ≈ 715 Mbit/s. Over four lanes that is 715 / 4 ≈ 179 Mbit/s per lane; over two lanes, 715 / 2 ≈ 358 Mbit/s per lane.

The decision: MIPI D-PHY lanes run from 80 Mbit/s per lane up to 1 to 2.5 Gbit/s per lane by PHY version, so both counts carry this format at 30 fps. At 60 fps the two-lane figure doubles to about 715 Mbit/s per lane, which only newer D-PHY silicon accepts — check the receiver's documented per-lane maximum, then declare bus-width to match the lanes you actually routed. The arithmetic never justifies declaring lanes you did not wire. Where the host caps formats or sizes before the camera negotiates, MIPI CSI camera resolution limits: verify the host covers that boundary.

How do you tell a configuration fault from a dead data path?

Swap one known-good thing. If a reference camera module streams on the same connector and channel, the lanes, receiver and device tree are correct and the fault sits in your sensor's configuration; if the reference also fails, the problem is the board or the channel mapping.

Run the swap before anything invasive: it costs one ribbon cable and bisects the fault between sensor-side configuration and board-side delivery. Keep one tested reference module on the bench for exactly this purpose on every CSI program.

If you have a scope, watch the clock lane during a stream attempt. A CSI clock pair toggles only while the sensor transmits; an idle trace at the attempt means the sensor is not streaming at all, which sends you back to rails and clocks rather than lanes. When data arrives but frames come out wrong, or the receiver logs errors, suspect the format declaration: compare the media-ctl pad format with what the driver programs. A mismatch can trip receiver error paths, as described in MIPI CSID lane0 FIFO overflow: sensor probes but preview is black. Geometry mismatches fail at capture too — raw V4L2 capture refuses frames when the declared height is undersized, which this V4L2 raw capture failure on undersized frame height reference walks through.

When should you choose a standard interface instead of debugging CSI?

Choose USB3 or GigE when the schedule matters more than the cable. A board camera over USB3 or GigE needs no lane matching, no regulator sequencing and no receiver tuning: module, cable and interface arrive tested as one unit, and the same machine design keeps working.

CSI keeps the edge on cable width, latency, power draw and unit cost at volume, which is why it remains right for tight embedded designs. Standard interfaces win on bring-up time and serviceability: board-level cameras with USB3 or GigE drop into the same housing on one cable, and the camera finder filters them by sensor format, mount and interface. The selection logic for embedded machines is in Board level camera selection for embedded vision machines, and Board camera evaluation checklist for inspection systems covers the acceptance tests before you commit a design.

Three drop-ins cover the common cases. The MV-CB016-10GM-M-W pairs a 1/2.9" sensor, a global shutter and an M12 mount on GigE.

The LS-BCM-0003 raises the rate: 3.1 MP at 120 fps over USB3 on a 1/1.8" IMX252 with a global shutter.

The LS-BCM-0020 covers 6.3 MP at 18 fps over GigE with an IMX178 rolling shutter in a CS-mount.

Check mount, sensor format and interface fit before ordering any module; the verification list is in Camera module interface compatibility: what to verify.

What prevents a silent CSI failure on the next board?

Design for the test: one test point per rail, an enable line you can force, a known-good channel reserved for the reference module, and the device tree copied from the reference design end to end. The first stream attempt then either works or points at the one thing you changed.

• A test point on every sensor rail and on reset. A meter probe on a named point settles the power question in a minute; without it, every no-ack becomes an hour of silkscreen archaeology.
• Regulator enables routed to GPIOs you can drive from userspace. Forcing one rail on separates a switching fault from a sequencing fault in a single step.
• One CSI channel and connector reserved for the reference module. The swap test stays available for the life of the board.
• The device tree carried over from the reference design and changed one property at a time. A one-line diff is a diagnosis; a rewritten overlay is a new unknown. When an overlay stops loading at all, the failure moves earlier, as covered in Camera driver device tree mismatch: diagnose missing DTBs.
• The passing v4l2-ctl command written into the board's test plan. Re-run it after every release move or overlay change; the command that proved the board once proves it again.

More platform-level debugging guides sit on the systems topic page. When the machine design is ready for parts, the camera configurator steps through camera, lens and light in order, or ask us through the contact page.