MIPI CSID lane0 FIFO overflow: sensor probes but preview is black

The sensor probe logs success, the stream starts, and the preview stays black while the kernel prints CSID lane0 FIFO overflow. That pair of facts carries more information than it seems to: your I2C control path is proven, and your MIPI CSI-2 data path is delivering nothing the receiver can use. This guide is for engineers bringing up a CSI-2 camera module on an embedded board. You will read the two log lines correctly, prove the platform path with two swaps, check the five parameter-file declarations, compute the lane rate and the receiver budget, and scope the PHY — then commit to a parameter fix, a module replacement or an interface change.

What does CSID lane0 FIFO overflow tell you?

It tells you the camera's control path works and its data path does not: the sensor answered on I2C with the expected ID, but once streaming began the receiver's lane FIFO filled faster than it drained, so no complete frame reached memory.

The kernel prints two different subsystems in those lines. CAM-SENSOR is the I2C world: an I2C master read the chip ID at the declared slave address and received the expected value. CAM-ISP with the CSID tag is the MIPI receive world inside the SoC, and its line is an interrupt status, not a probe result — the lane merger's FIFO filled past capacity while frame data was expected. The driver even names its two suspicions: skewed or missing data on the lanes, or a receiver clock too slow. The 400000000 Hz figure is the CSID clock read from the clock tree, 400 MHz. Treat both as hints to test, not verdicts.

Why does the sensor probe succeed and the preview still come up black?

Because probe success proves only the I2C register interface: the receiver read a valid sensor ID at the expected slave address, and none of that exercises the MIPI lanes, which are clocked, configured and powered separately from the sensor core.

Probe and streaming exercise different hardware. The probe runs at power-on with the MIPI PHY parked in its low-power stop state; the lanes carry nothing. At streaming start the sensor's PLL begins, the D-PHY leaves the stop state, and packets must appear with the declared lane count, bit rate, data type and virtual channel. Probe success tells you nothing about any of that. Two neighbouring faults have their own guides: if no video device node ever appears, that is the devicetree chain problem; if the probe itself fails with a wrong or missing ID, work the camera I2C communication failure path instead.

Which cause is most likely when lane 0 overflows?

Rank the causes in this order: a parameter-file mismatch on lanes, bit rate, clock mode, data type or virtual channel; a module that never drives valid MIPI data; a receiver that cannot ingest the rate; and only then signal integrity on the flex.

Work the list in this order and stop at the first test that convicts:

1. Parameter-file mismatch. Lane count, bit rate, clock mode, data type or virtual channel declared differently from the module's real output. Test: compare all five against the module's MIPI output specification.
2. A module that never drives valid MIPI data. Wrong init sequence, missing supply on the MIPI output stage, or a dead module. Test: scope lane 0 while streaming.
3. Receiver throughput below the incoming rate. The CSID clock, or the capture pipeline behind it, cannot absorb the payload. Test: the arithmetic in the next two sections.
4. Signal integrity on the flex. Long ribbon, stubs, missing ground plane. Test: the shortest-cable swap.

Most black-preview cases close at 1 or 2, and a marginal cable usually passes with a short flex, which is why signal integrity ranks last. If the failure pattern is wider than one interrupt line, the general MIPI CSI camera no images checklist narrows it quickly.

How do you prove the platform path is good before touching settings?

Run two swaps on the same adapter, flex and connector: a known-good module of another model that streams normally proves the receiver, port and wiring, and a 60 mm flex replacing the long one with no change in the error rules signal integrity out.

Both substitutions take minutes. The module swap hands the fault to your module's output or its parameter set; the cable swap clears signal integrity at a stroke when nothing changes. Reverse the experiment before ordering anything: put your suspect module on a board where another module already streams. If it produces frames there, the module is innocent and your receiver-side numbers are wrong.

When you genuinely need cable length, the CSI camera extension cable compatibility checks list what to confirm before trusting a long run.

What must the parameter file match about the module?

Five declarations must match the module's real MIPI output: lane count, per-lane bit rate, clock mode, data type and virtual channel; when one disagrees, the receiver assembles nonsense or starves, and the overflow interrupt names lane 0 first.

Each declaration lives in the sensor driver's parameter or devicetree entry for the module. The five, and how each mismatch shows up in this exact error:

• Lane count. A two-lane module declared as four gives the receiver less data than declared — the Skew/Less Data on lanes hint in your log.
• Per-lane bit rate. Set by the sensor's PLL registers; a declaration the PLL cannot reach leaves the PHY dead or drifting.
• Clock mode. Continuous versus non-continuous: a receiver expecting a continuous clock starves between bursts when the sensor drops the clock lane.
• Data type. RAW10 packed is not RAW8; a mismatch shifts every byte the unpacker sees and corrupts framing.
• Virtual channel. Frames tagged VC1 while the receiver listens on VC0 look exactly like missing data.

Change one declaration at a time, then power-cycle and reset before each retest. The lane-count choice has a probe-side twin — the two-lane versus four-lane sensor probe failure guide covers it — and the camera module interface compatibility checklist lists the rest of the handshake.

How do you compute the lane rate the link must carry?

Multiply active pixels, bits per pixel and frame rate, then divide by lanes: a 4056 × 3040 RAW10 sensor at 30 fps on four lanes moves about 0.93 Gbit/s per lane on average, so a parameter file declaring less cannot carry the stream.

Compute what the wire must carry before you touch any setting:

Worked example, 4056 × 3040 RAW10 at 30 fps on four lanes:

• 4056 × 3040 = 12,330,240 pixels per frame
• × 10 bit = 123,302,400 bit per frame
• × 30 fps = 3,699,072,000 bit/s of payload
• • 1% packet overhead ≈ 3.74 Gbit/s aggregate
• ÷ 4 lanes = 0.93 Gbit/s per lane, average

The average is not what the receiver clocks, because pixels travel only during active lines. At the usual 75–85% active-line duty the burst rate sits 20–35% above average, so declare 1.2 Gbit/s per lane — a 600 MHz D-PHY clock — and check the sensor PLL can reach it. Compare your parameter file against these numbers: two lanes declared at 1.0 Gbit/s carry 2.0 Gbit/s, about 54% of what the frame needs, and the link starves before one frame assembles. The companion piece on MIPI camera lane bandwidth and frame-rate limits extends this arithmetic to lane and frame-rate trade-offs.

When is the CSID clock genuinely too slow?

Divide the payload rate by the CSID clock: the example needs 3.74 Gbit/s ÷ 400 MHz ≈ 9.4 bits consumed per clock, so an 8-bit ingestion path caps at 3.2 Gbit/s and overflows, while a 16-bit path runs with about 70% headroom.

The overflow is an input/output race inside the receiver: bytes arrive from the PHY faster than unpacked pixels drain toward memory. Capacity equals the CSID clock times the bits it consumes per clock. The log prints the clock — 400000000 Hz, read from the clock tree — because a slow receiver clock is one of the two classic causes. The clock is negotiable; the width is a fixed per-SoC design fact, in the reference manual's capture-pipeline chapter. Raising the receiver clock from 400 MHz to 600 MHz lifts an 8-bit path from 3.2 Gbit/s to 4.8 Gbit/s, and the worked example then fits with 28% margin.

Where the clock tree will not give more, shrink the stream: lower frame rate, crop, or a narrower data type. The same host-side ceiling decides MIPI CSI camera resolution limits, so a resolution change belongs in this arithmetic. One further trap on multi-camera receivers: the capture pipeline behind the CSID can itself be the bottleneck, and the tell is an identical module passing on one port while the other overflows. The fix there is a smaller stream or a different port, not another parameter file.

What must the scope show on the clock lane and lane 0?

While the pipeline streams, the clock lane must show a differential clock at the declared frequency and lane 0 must show high-speed bursts on every active line; a lane 0 that stays in its low-power idle state while the clock runs convicts the module.

Scope while the pipeline is actually requesting frames — many pipelines raise the lanes only once streaming starts. A differential probe is ideal; even a single-ended check answers whether anything switches at all. Then read the trace against three expectations:

• Clock lane: continuous or gated differential clock at the declared frequency; the bit rate is twice the clock frequency, so a declared 1.2 Gbit/s per lane must appear as 600 MHz.
• Lane 0: high-speed bursts aligned to active lines, returning to the low-power stop state between them.
• Lane 0 behaviour: bursts that stop early, or run free without frame sync, point at lane-count or framing declarations.

The decision falls straight out of the trace. No clock means sensor PLL or module supply. A clock with no lane 0 bursts means the module's data path or the lane declaration. Bursts at the wrong frequency mean the bit-rate declaration. Bursts at the declared rate with the overflow still firing mean the receiver side, per the previous section. A clean trace also closes the cable question for good.

When should you stop debugging CSI and change the interface instead?

When the scope shows a healthy link and the budget arithmetic still leaves no receiver margin, or no parameter set for your module has been validated on your SoC, stop: move the camera to USB3 or GigE and reclaim the integration time.

Carry four habits into the next integration so this fault never reaches the bench:

• Keep a known-good module per adapter for the two-way swap.
• Power-cycle the module and reset the receiver after every overflow before retesting.
• Compute the lane-rate and ingestion budgets before choosing a module, and declare 20–35% burst headroom.
• Store parameter files per module and per SoC, with lanes and bit rate in the file name.

When you do leave CSI behind, the debug changes shape: a USB3 or GigE board camera — the board-level cameras — talks to a host driver over a standard cable, the receiver-clock fight disappears, and cables run in metres rather than centimetres. The camera data cables and the modules below are that path.

The LS-BCM-0003 streams 3.1 MP at 120 fps over USB3 with a global shutter.

For the two other common fallbacks, a 6 MP USB3 board camera covers bandwidth and a 1.6 MP GigE module covers cable length.

If the inspection keeps its direct-to-SoC requirements, take the board level camera selection guide with you, narrow the hardware with the camera finder, and finish the build in the camera configurator. When a stubborn module is the last blocker, the contact page is the route to a swap recommendation. The systems topic page collects the rest of the bring-up guides.