A camera module that probes cleanly on one embedded host refuses to appear on another, and the log blames the sensor driver rather than the cable. The usual cause is lane count: the module is strapped in hardware for 2-lane MIPI output, the host's driver carries only 4-lane entries for that sensor, and no software change can create a wire pair the board does not route. This guide shows you how to read the strap that selects the lane mode, why the mismatch fails at the I2C ID read instead of at the pixel link, the bandwidth arithmetic that decides how many lanes your resolution and frame rate need, and the fix paths in order of preference.
The symptom: probe failed on the host that should support it
The module runs on the host it shipped for. Move it, with its cable, to a host that supports the same sensor at full resolution, and the camera subsystem logs a probe failure for that sensor's driver at every connector slot. A typical line names the driver entry (one IMX577 host prints it as cmk_imx577), the slot number, the I2C slave address 0x34 and the expected sensor ID 0x577, repeated for each slot the connector supports. On the bench the two module variants look identical: same PCB revision marking, same FFC connector, same sensor label. The one visible difference is where a 0-ohm resistor is populated.
A failed ID read has a decision tree of its own, separate from the strap question here. If your log's address or ID differs from the module's documents, start with MIPI camera sensor ID mismatch: diagnose the wrong I2C probe.
The lane count is set by a strap, not by software
MIPI CSI-2 carries image data over one clock pair and one to four data pairs. The sensor die often supports 2-lane and 4-lane output, but what leaves the module is fixed by how the carrier PCB is populated. On families that build two variants from one PCB, the difference is one or two 0-ohm resistors: the populated position wires two data pairs to the connector, or all four, and it usually sets a matching power-up strap the sensor reads at reset. When a product page says a module supports 2-lane and 4-lane MIPI, that describes the die; the resistor decides what the built module does, and firmware does not reach the resistor.
That makes the bench test exact. When two variants share a PCB revision, the populated strap position is the variant. Photograph both sides of your module next to the maker's variant images and the question answers itself.
Why the mismatch fails at the probe, not at the pixels
A sensor probe runs in a fixed order: the driver enables regulators, releases reset, waits for the clock to settle, then reads the two-byte ID register over the I2C control bus. Lane count plays no part until that read succeeds. A lane mismatch still kills the probe because the strap network rarely carries lanes alone. On two-variant PCBs the same strap often routes an enable or reset level, so a module strapped against the driver's expected power-up sequence never presents a working I2C interface. The ID read returns nothing, and every slot logs a failure.
There is a second, quieter failure mode. The ID read passes, but the receiver has no mode entry at the module's lane count, so the driver rejects every stream configuration. Your log separates the two cases cleanly. No ID read at all points at power, reset, strap or I2C wiring; an image sensor that is not detected usually fails right there. A valid ID that will not stream points at the lane and mode tables.
Likely causes, in order of probability
- The module is the 2-lane variant. Highest probability when the PCB matches a working 4-lane module and one resistor sits elsewhere. Test: compare the strap position against the maker's variant photos or strap table, and check the shipped default lane mode on the product page.
- The strap gates the power-up level, so the sensor never answers I2C. Test: scan the sensor's I2C bus for its documented address before the driver binds. An absent address while the module has power means the sensor is unpowered or held in reset.
- Wrong or reused FFC cable. Variants in one family ship with different cables, and a 22-pin cable carried over from the other variant can route different pairs or sit reversed. Test: fit the cable specified for the variant you are running and check the pin-1 marking against the socket.
- No host mode entry at your lane count. Test: read the receiver's mode table for your sensor. If every entry assumes four data lanes, a 2-lane module cannot stream even after a clean ID read.
- Seating and physical damage. Test: reseat the FFC, inspect the contacts, and confirm the connector latch is closed.
The bandwidth arithmetic behind the two straps
Lane count sets how much pixel data the module can move, so estimate the wire rate before you pick a variant.
Worked example: a 12.3 MP sensor at 30 fps, raw 10-bit output, 20% blanking and packet overhead.
- Pixels per second: 12,300,000 px × 30 fps = 369 Mpx/s
- Payload: 369 Mpx/s × 10 bit/px = 3.69 Gbit/s
- On the wire: 3.69 Gbit/s × 1.2 = 4.43 Gbit/s
- Four lanes: 4.43 Gbit/s ÷ 4 = 1.11 Gbit/s per lane
- Two lanes: 4.43 Gbit/s ÷ 2 = 2.21 Gbit/s per lane
Typical mobile-class MIPI D-PHY links run about 0.8 to 1.5 Gbit/s per lane, so the 4-lane split fits with margin and the 2-lane split lands near twice a practical ceiling. Halve the frame rate to 15 fps and the stream halves to 2.21 Gbit/s, or 1.11 Gbit/s per lane: the 2-lane strap buys full resolution at about half the frame rate. That trade is why the 2-lane SKU exists for hosts that cannot accept four pairs. The inputs move the result: 10% blanking instead of 20% drops the wire rate to 4.06 Gbit/s (1.02 and 2.03 Gbit/s per lane), and 12-bit output raises the payload by 20%.
The same arithmetic sits behind MIPI camera lane bandwidth: what limits frame rate, and the receiver-side checks in MIPI CSI camera resolution limits: verify the host.
Tests to run before you change anything
- Read the strap: power off, ground yourself, and compare the 0-ohm positions against the maker's variant table or photos.
- Scan the I2C bus with an address-scanning utility before the driver binds and look for the sensor's documented address. Present means power and strap are probably fine; absent means fix power-up first.
- Match your log line to the module's documented ID and address before blaming the strap.
- Read the lane declaration in the host's device tree; a missing or stale entry fails for reasons unrelated to your module, which the device tree mismatch guide covers.
- Compute the per-lane rate from the formula above and confirm a mode entry exists at your lane count, resolution and frame rate.
When the bus scan comes up empty, the I2C communication failure guide walks the probe-level checks in detail.
Fixes, in order of preference
- Fit the variant strapped for your host. When the family includes a 4-lane module for your host, that SKU is the supported answer: same sensor, correct strap from the factory, no rework.
- Move the strap only where the maker publishes the change. Follow that procedure exactly: same resistor value, correct pads, then re-check the I2C address before reassembly.
- Match the host side once the strap agrees. Set the lane entries in the device tree and select a driver mode that exists at your lane count. A host whose sensor entries ship 4-lane modes only cannot be configured onto a 2-lane module.
- Sidestep MIPI while the interface is still your choice. A USB3 or GigE board-level camera enumerates as a standard device on the host: no lane strap, no mode table to reconcile. When that route fits, these are the parts to start from:
- Sensor format
- 1/1.8"
- Interface
- USB3
- Sensor format
- 1/1.8"
- Lens mount
- C-mount
- Sensor format
- 1/1.8"
- Lens mount
- CS-mount
The MV-CB060-10UM-B is a bare board with a 6 MP, 1/1.8" mono sensor on USB3. The LS-BCM-0003 adds a C-mount and a global shutter running 120 fps (3.1 MP, 1/1.8"). The LS-BCM-0020 covers the same ground over GigE at 18 fps (6.3 MP, CS-mount). Browse the board-level cameras category or the camera finder, and the board level camera selection guide for embedded vision machines walks the full trade-off.
Prevention: match lane counts at design time
- Get the host's sensor mode table, not the marketing phrase: the table lists which lane counts, resolutions and frame rates have entries.
- Order the module variant whose strap matches the host, and keep each FFC with its module.
- Check the driver's expected I2C address against the module's documented address before integration.
- Compute the per-lane rate for your worst-case mode and keep about 20% margin under the receiver's lane ceiling.
- Bench-test the ID read before mechanical integration; five minutes on the bench catches strap and power faults early.
For modules and hosts from different sources, the camera module interface compatibility guide is the pre-order pass, and the systems topic page gathers every guide of this kind.
Compact cameras to build in
120 models · from $179.00The decision, case by case
- Host strictly 4-lane, module strapped 2-lane: there is no software fix. Use the variant strapped for 4 lanes, or the maker's published strap procedure. Anything else is time spent proving the same result again.
- Host configurable to 2 lanes: declare two lanes on both ends and select a mode entry at that lane count. Accept its frame-rate cap, about half the rate at full resolution in the worked example.
- Full frame rate is non-negotiable and no 4-lane variant is available: change the interface. A USB3 or GigE board-level camera, or a host whose receiver mode table matches the module, are the two working exits.
If you are weighing module variants against a host change, start at the camera configurator, or reach us through the contact page and we will match lane counts, cables and hosts with you.
Questions
Can a 2-lane MIPI camera ever work on a 4-lane host?
Yes, when the host's driver ships a mode table entry for it. A CSI-2 receiver can be configured to use two of its four data pairs, and many receivers accept a 2-lane module without complaint. The failure in cases like this one is the opposite direction: every sensor entry on the host assumes the 4-lane-strapped variant, so a 2-lane module matches no mode and never gets past the ID read.
What exactly does moving the strap resistor change?
A 0-ohm resistor moved between two pad positions re-routes the module's lane wiring: one position wires two data pairs to the connector, the other wires all four, and on two-variant PCBs it can also switch a power-up strap level. The sensor samples that strap the moment power is applied, long before any driver runs, which is why no configuration file can reach it.
How do I read the lane count my host expects?
Open the camera port entry in the host's device tree: the endpoint for the CSI-2 receiver lists the data lane indices it drives, four entries for a 4-lane port. Cross-check that list against the receiver driver's mode table for your sensor; if every entry assumes four lanes, a 2-lane module has no mode to fall back to.
Why does the log list probe failures for sensors I never connected?
The camera subsystem probes every sensor driver entry the host image defines against each connector slot, so a normal boot logs failures for several sensors that are not present. Treat those as noise. The line that matters is the entry whose expected sensor ID matches your module's die; if that one fails, the module never answered the ID read at the listed address.
Does the strap change the sensor's I2C address or ID?
No. The ID register value and the control address belong to the sensor die, so a module of this family expects 0x577 at address 0x34 whichever lane mode is strapped. A strap mismatch shows up as no answer at all, or as a streaming failure with a valid ID. A different ID in the log points at the wrong driver entry, not at the strap.