MIPI CSI stream timeout after two seconds: short frame error

If you bring a raw MIPI CSI-2 sensor onto an embedded board, few failures waste more bench time than a camera that runs for two seconds and then times out. The video looks clean while it lasts, the pipeline dies mid-stream, and a restart will not stream again until power is cycled. The trace tells the real story and the arithmetic decides the fix. Work through it in order: compute the lane budget with the driver row's own numbers, read the receiver tags that confirm the shortfall, match the caps to a mode row that closes the budget, then recover a receiver that a failed stream leaves latched.

Compute the lane budget before anything else

A CSI link is a pipe with a fixed rate. Three numbers size the demand: the mode's active pixels, the bits per pixel of the raw packing the sensor transmits, and the frame rate. One number bounds the supply: lanes multiplied by the per-lane bit rate the driver programs.

The 1.25 target has a basis. The same lanes carry horizontal and vertical blanking, embedded data lines and PHY overhead, so active pixels alone understate the wire load; a link sized at exactly 1.0 leaves nothing for them.

Worked example, using the numbers from a real trace: an 8064×6016 sensor at 15 fps in RAW10 on three lanes at 1.6 Gbit/s.

• Active pixels: 8064 × 6016 = 48,513,024 per frame.
• RAW10 frame payload: 48,513,024 px × 10 bit = 485,130,240 bit ≈ 485 Mbit.
• Payload rate: 485,130,240 bit × 15 fps = 7,276,953,600 bit/s ≈ 7.28 Gbit/s.
• Link rate: 3 lanes × 1.6 Gbit/s = 4.8 Gbit/s.
• Margin: 4.8 ÷ 7.28 = 0.66.

The link carries two-thirds of the payload and is short by 2.48 Gbit/s. The timing agrees: one frame needs 485 Mbit ÷ 4.8 Gbit/s = 101 ms of pure payload against a frame period of 1 ÷ 15 = 66.7 ms, so the sensor falls behind from the first frame.

The raw packing does not rescue the mode. At this resolution and frame rate, RAW8 still needs 48,513,024 × 8 bit × 15 = 5.82 Gbit/s and RAW12 needs 8.73 Gbit/s; nothing fits through 4.8 Gbit/s. Keep the capsfilter's format out of the link calculation: NV12 at 15 fps works out to the same 8.73 Gbit/s, about 1.09 GB/s, because NV12 is also 12 bit per pixel — but that is ISP-to-memory traffic after capture, not what crosses the lanes.

For the general method, the guide on MIPI camera lane bandwidth covers what constrains a link, and the CSI-2 frame rate estimation walkthrough derives a mode's data rate from its lane count.

Read the trace: the tags confirm the shortfall

The pipeline in that trace is a gst-launch-1.0 run with nvarguscamerasrc sensor-id=0 feeding a capsfilter that requests 8064×6016 NV12 at 15 fps. Turn on the camera stack's tracing — the log that prints rtcpu_vinotify_error and rtcpu_nvcsi_intr lines — and the failure writes itself down:

• PHY_INTR0 status bits latch at stream-on: the physical layer reports a lane-level disturbance.
• A CSIMUX_STREAM error follows on the first frames.
• On each frame: frame start (FS, ATOMP_FS), embedded data lines (CHANSEL_EMBED_SOF, CHANSEL_EMBED_EOF), the first pixel line (CHANSEL_PXL_SOF), a run of ATOMP_FRAME_NLINES_DONE events, then frame end (FE) paired with CHANSEL_SHORT_FRAME.

That last pairing is the diagnosis. The receiver armed itself for the mode's declared height, accepted frame start and the embedded lines, and reached frame end before the declared number of pixel lines arrived. PHY_INTR0 at the same moment says the lanes stumbled while trying.

The two seconds of video are buffer fill, not a working camera. With payload at 101 ms per 66.7 ms frame period the sensor is behind from frame one; pipeline buffers bridge the gap for roughly the two seconds you saw, then the application times out waiting for frames that never complete. Treat that shape — runs, then dies after a working period — as a link budget failure first; a walkthrough of a CSI camera timeout after a working period covers the same pattern on another embedded stack.

What the arithmetic decides

• Full resolution at 15 fps is unattainable on this link in any packing. Do not spend the day on software.
• The full-resolution ceiling with margin is 4.8 Gbit/s ÷ (485,130,240 × 1.25) ≈ 7.9 fps in RAW10. If the application tolerates it, that mode closes the budget exactly.
• Adding a lane does not rescue 15 fps: four lanes at 1.6 Gbit/s give 6.4 Gbit/s, still below the 7.28 Gbit/s payload. Holding 15 fps with margin needs 7.28 × 1.25 = 9.1 Gbit/s — four lanes at 2.27 Gbit/s each, or eight lanes at 1.14.
• The 4K mode is the row that works. 3840 × 2160 = 8,294,400 px; × 10 bit = 82.9 Mbit per frame; at 15 fps that is 1.24 Gbit/s against 2.4 Gbit/s of link from three lanes at 800 Msps — a 1.9× margin, and the same row sustains 2.4 Gbit/s ÷ (82.9 Mbit × 1.25) ≈ 23 fps before it crosses the 1.25 line. That is why the lower-rate mode streams clean while the full-resolution row dies.

Match the caps to a driver mode row

A sensor driver binds every supported mode to a row: width, height, raw bit depth, lane count and per-lane rate. Both checks run against that row. The capsfilter must request the row exactly — resolution, format and frame rate. And the row's lane count and rate must clear the budget from the first section; a row that exists but fails the arithmetic streams badly no matter how correct the caps are.

The test that separates budget failure from configuration failure: stream the known-good row — the 4K one — for a few minutes. If it holds, power, wiring and the receiver are fine and the full-resolution row's arithmetic was the fault. The dedicated guide on CSI camera short frame errors and mode matching walks that matching step in detail.

Recover the stuck receiver

A stream that dies at the physical layer can leave the receiver or its deserializer latched in a bad protocol state. Restarting the pipeline re-arms the software but not the PHY, which is why the retry never streams until a power cycle. The fix is small: remove power from the camera module for a few seconds after every failed run, then stream the known-good mode. Reserve full reboots for driver or device-tree changes. If the short-frame signature returns immediately after a clean power-up, the budget is still broken — go back to the first section.

Bring-up order matters too: power and clocks settled before the mode is programmed, the mode programmed before stream-on. The guide on streaming failures from power, clocks and the device tree covers that sequence.

When the per-lane rate doubles, check the physical layer

Moving a mode from 800 to 1600 Msps per lane halves the eye the receiver sees, and PHY_INTR0 status bits that latch at stream-on are that physical layer complaining. Seat the connectors, shorten the flex, and confirm the module and its cabling are qualified for the row's rate. Keep the order straight, though: signal-integrity work cannot create 2.48 Gbit/s the budget never had. Close the budget first, then clean up the PHY bits; chasing the eye while the mode is impossible wastes the effort twice.

Fixes that will not work

• Longer sink timeouts or larger queues. Buffering delays a timeout; it cannot create the 2.48 Gbit/s the link is short.
• Lowering the framerate in the capsfilter while leaving the mode row unchanged. The sensor streams at its programmed row's rate and the receiver still comes up short.
• Retrying without a power cycle. The latched PHY state survives every restart until the module loses power.
• Suspecting I2C. Frame starts, embedded data and pixel lines all arrive, so the sensor is streaming. Control-side and link-side failures differ, and the guide on separating I2C from MIPI failures shows the tests for each.

If you can choose the interface, buy the bandwidth

Where the platform offers USB3 or GigE alongside CSI, a board-level camera on those interfaces takes lane budgeting out of your design: the link rate belongs to the interface standard and its bridge silicon, not to your mode table. Match the bridge before committing to a USB3 module — the guide on matching a board-level camera to a USB3 bridge board covers the pairings.

Inspection work that needs more resolution or frame rate than a board camera carries is the territory of area scan cameras on GigE, USB3, 10GigE or CoaXPress, each with a specified, fixed link rate.

Two GigE board-level cameras that cover common inspection resolutions:

The LS-BCM-0020 pairs a 6.3 MP IMX178 sensor with a CS-mount and an 18 fps GigE stream. The MV-CB016-10GM-M-W carries a 1.6 MP global shutter behind an M12 mount for compact builds.

Re-test checklist

1. Budget closes at 1.25 or better, using the driver row's width, height, bits per pixel, fps, lanes and per-lane rate — arithmetic rejects impossible modes before hardware time is spent.
2. Capsfilter equals one mode row exactly, because the receiver times frames against that row's declared height.
3. Lane count and per-lane rate in the row match the module's wiring, since a module wired for two lanes on a three-lane row drops lines silently.
4. Module power-cycled after every failed run, because a latched PHY poisons the next test.
5. One change per test — mode, lanes or cable, never two at once.
6. A pass looks like this: no CHANSEL_SHORT_FRAME in the trace, and one completed frame per frame period, 66.7 ms at 15 fps.

The decision for each case

• 8064×6016 at 15 fps on 3 × 1.6 Gbit/s: unattainable — 7.28 Gbit/s of RAW10 payload against 4.8 Gbit/s of link. Take the ≈7.9 fps ceiling, a smaller mode, or four lanes at 2.27 Gbit/s each.
• Streams two seconds, then dies, CHANSEL_SHORT_FRAME on every frame: link budget. Move to a row that clears it with margin.
• Streams once, never again until a power cycle: latched receiver. Power-cycle the module, then fix the row before the next run.
• The 4K row at 800 Msps per lane: 1.9× margin. Keep it as the working mode while everything else is validated.
• Full resolution genuinely required at speed: change the interface, not the software — a USB3 or GigE board camera, or an area scan camera on a faster link.

Compute the budget first, read the trace second, check the mode row third — that order settles this failure in an afternoon. To spec a camera path with the bandwidth already closed, the camera finder filters by interface, resolution and shutter, and the team answers through the contact page when a build needs a second opinion.