MIPI CSI camera connector pinout: read it before you match a camera

Two camera connectors on the carrier, one camera module in your hand, and no frames: that is the MIPI CSI matching problem. The flex plugs in, the latch closes, and the camera still never comes up, because a connector that fits says nothing about the pinout under it. This guide shows you how to read a MIPI CSI camera connector pinout on both ends: group the pins into power, ground, I2C and lane pairs, run the lane-rate arithmetic for your resolution and frame rate, and decide match or no-match before you order anything. When the pinouts disagree, you will also know which fallback — a mapped adapter flex or a USB3 board camera — costs less time.

The four pin groups and the rule that decides a match

Every MIPI CSI-2 camera connector, whether it has 15 pins or 31, carries the same four groups. Power pins feed the module — most modules want a low-voltage I/O rail plus a higher supply rail. Ground pins return the lane currents and are usually interleaved between the differential pairs. The I2C control pair, SDA and SCL, carries register access; no video ever flows on it. The differential pairs carry the video: one clock lane pair, then one pair per data lane, two pins per lane. The counting rule from the CSI-2 design is simple — a link with a clock lane and two data lanes occupies six signal pins, and four data lanes plus the clock take ten.

From that comes the matching rule: a camera and a carrier work together only when every group maps one-to-one between the two pin tables. A flex sliding into a connector is a coincidence of pin count and pitch. It proves nothing about lanes, I2C or power.

Read the carrier side: the pin guide, not the silkscreen

Start with the carrier's connector pin guide. Board vendors publish it in their support or documentation downloads, keyed to board revision, and it is the authoritative source; the silkscreen reference designators such as CN4 and CN5 only tell you which connector the table describes. Check each designator separately — on some boards both camera connectors share one table, on others they differ in lane count.

A usable pin guide states five things pin by pin: lane number and polarity (P or N) for each differential pin, which I2C bus and pins carry SDA and SCL, the voltage of every power pin, the grounds, and any control lines such as module enable or strobe. If your carrier ships only a schematic, extract the same five fields and write your own table; twenty minutes with the schematic beats a dead camera.

Add one more field on the host side: how many lanes the controller actually drives. A four-lane connector on a host that enables two lanes still runs a two-lane camera when the pins line up, but it will not run a four-lane sensor at full frame rate. The MIPI 4-lane camera on a devkit carrier board: check lanes first guide walks that check, and the MIPI CSI camera resolution limits: verify the host guide covers the host's ceiling. On an embedded AI module carrier, the same CSI pinout compatibility check for an embedded AI carrier applies.

Read the camera side: the module's own pin table

The camera module's datasheet supplies the other half: its data-lane count, its pin order table, its I2C address, its power rails with their power-up order, and — the field people miss — the flex contact direction. Two flexes with identical pin counts can put pin 1 on opposite sides, which mirrors every signal on the bus. Common camera flexes are 22-pin at 0.5 mm pitch and 15-pin at 1.0 mm pitch; pitch, pin count and contact side must all agree before anything else matters.

The I2C pair needs one decision: the module's 7-bit address, printed in the sensor datasheet, must be free on the carrier's bus. Two cameras sharing one address is common enough that the bus options that work for two sensors with the same I2C address are worth reading before you plan a two-camera carrier.

The latch tab on some carrier connectors is fragile; if it cracks, CSI connector tab repair options are worth reading before you reach for glue.

The five checks that decide a match

Put both pin tables side by side and run five checks, one per group. A single failure anywhere means no direct connection — fix the group that failed rather than re-seating the same flex and hoping.

Worked example: a 2-lane camera on a 31-pin, 4-lane carrier connector

This is the case behind most "do you have the pinout?" questions: a carrier connector with 31 pins documented for four data lanes plus a clock, and a two-lane camera module someone wants to hang on it. The decision has two halves — do the pins agree, and are two lanes enough bandwidth?

Inputs. Carrier side, from its pin guide (the reader's case): 31-pin FFC, four data lane pairs plus one clock pair — 10 signal pins — with the remaining 21 pins carrying grounds, I2C, power rails and control lines. Camera side, as a typical board-camera spec (example inputs — read yours from the module datasheet): two data lanes plus clock, a 1920 × 1080 sensor streaming raw 10-bit at 30 fps, on a 22-pin 0.5 mm flex end.

Rule. First test, pins: the camera's three pairs must land on carrier lane pins with the same numbering and polarity — and a 22-pin camera end cannot enter a 31-pin carrier connector, so a mapped adapter or a camera built to that pin guide is required. Second test, bandwidth: lane rate equals pixel rate, times bits per pixel, times blanking overhead, divided by data lanes.

Arithmetic. 1920 × 1080 = 2,073,600 pixels per frame; at 30 fps that is 62,208,000 pixels per second. Raw 10-bit makes the payload 622,080,000 bit per second. Row and frame blanking add roughly 20 percent on this class of sensor: 622,080,000 × 1.2 = 746,496,000 bit per second. Over two lanes: 746,496,000 ÷ 2 = 373,248,000 bit per second per lane — call it 373 Mbit/s per lane. Each extra 10 percent of blanking moves that by 622,080,000 × 0.10 ÷ 2 ≈ 31 Mbit/s per lane.

Result and decision. D-PHY lanes run from 80 Mbit/s up to about 1 Gbit/s per lane in the first generations, and later revisions reach 1.5-2.5 Gbit/s per lane. At 373 Mbit/s per lane, two lanes carry this stream with margin — about 37 percent of a first-generation lane's ceiling. Double the frame rate and the pair carries 746 Mbit/s per lane, still inside the range; double the resolution as well and you are past 1 Gbit/s per lane, which means a four-lane sensor or a lower bit depth. On the pin side, the two lanes must map onto carrier lanes 0 and 1 through an adapter that also translates 22 pins to 31; without it, this camera does not connect, and hunting an adapter is usually slower than buying a camera made to the carrier's pin guide.

When the pinouts do not agree: three ways out

A mapped adapter flex. Adapter flexes translate pin order, contact side and pin count between ends. They fix exactly one group — the physical flex. They cannot fix a lane-count difference, a voltage mismatch or an I2C address clash, and they add two connector interfaces' worth of contact resistance to the link.

A camera made for that pinout. Module vendors build camera boards against specific carrier pin guides. The board level camera sensor compatibility: match the host before you buy guide is the fastest way to screen a candidate module against your carrier's table.

A different interface. A USB3 or GigE board camera removes pin matching from the problem: the host sees a standard cable and a fixed bandwidth, and the camera module carries its own regulator and connector. USB3's link rate is 5 Gbit/s — roughly six times the 746 Mbit/s payload the two MIPI lanes carry in the worked example. Skip the pin exercise entirely when the host exposes USB or GigE anyway: the match question only exists on MIPI.

The LS-BCM-0003 fits that route: a 3.1 MP USB3 board camera, 1/1.8" global shutter behind a C-mount, streaming at 120 fps.

Two smaller options, if a 1.3 MP sensor on a 1/2.7" imager or a 6 MP bare board suits the space:

Filter by sensor format and interface in the board-level cameras category or the camera finder; for box-style factory cameras the area scan cameras page covers GigE and USB3.

Checks before you order

• Both pin tables printed side by side, each of the five groups marked pass or fail — nothing left as "probably fine".
• Flex pitch, pin count and contact direction confirmed on both ends; the adapter part number written down if one is needed.
• Lane count confirmed on the host driver side, not just the connector side.
• Power-up order from the camera datasheet checked against the carrier's rail sequence, and module current draw fitted into the rail's budget.
• I2C address checked for clashes on that bus, at a bus speed both ends accept.
• One camera ordered and raw frames streamed before any production quantity; the board camera evaluation checklist covers the tests that come after the connector.

Symptoms that point back at the pinout

When I2C answers but frames never start, MIPI camera not detected: I2C bus and device tree checks narrows whether control or data is the broken group, frames time out: separating I2C from MIPI failures sorts the rest, and a stream that survives the pin check but corrupts periodically often ends at pix_clk_hz corrected in the device tree.

Once every group passes, the rest is driver work. If the pin answer is no, the camera step of the configurator filters cameras by interface and sensor format so the match question disappears, the systems topic page collects the integration checks around it, and the contact page reaches the applications team when a pin table needs a second pair of eyes.