MIPI camera sensor ID mismatch: diagnose the wrong I2C probe

The symptom is distinctive: the same MIPI CSI camera module reports the correct chip-ID value on one single-board computer and a different, perfectly stable value on another. Swap the module between the two hosts and each one reproduces its own answer on every boot. That pattern clears the camera in a single step. It points at the host's sensor binding — a device tree node that names the wrong sensor driver, sets the wrong I2C address, or loads the overlay for the wrong lane count.

Work the checks in this order: prove the module on a known-good host, scan the I2C bus, then diff the sensor node property by property. You will finish knowing which side is at fault, which line to change, and when to stop fighting the host's driver package and move to a USB3 or GigE board camera instead.

Why does my MIPI camera read a different sensor ID on another board?

Because the ID is not stored in the cable or connector. The host's sensor driver reads a chip-ID register over I2C and compares it against the value compiled into that driver, so the same module returns 0x0354 under one board's driver and 0x0A56 under another's. The chip ID is a value in a sensor register, and a driver only finds it because its own ID table says which register to read, at which address, and in which width. Two hosts can therefore read two different answers from an unchanged module: each driver asks its own question.

In one representative case, a module that identified as 0x0354 on its reference host read 0x0A56 on a second board — a value that belongs to a different sensor in the same family. The bytes crossed the flex intact both times; the second host's driver simply read a different location. A driver written for a sibling part reads the offset where its own part keeps the ID. On your part that offset holds something else, and the something else often looks like another sensor's ID.

The module-to-host contract covers more than the connector pinout. MIPI CSI-2 camera compatibility beyond the connector and the camera module interface compatibility checklist list what must line up before an ID read means anything.

Is the camera broken if the wrong ID is stable across reboots?

No. A wrong value that is identical on every boot means the I2C read itself is clean, and something configured on the host is choosing the wrong register, the wrong address, or the wrong driver. Intermittent or all-zero reads are the hardware signatures; a stable ID is a configuration signature.

Rank the causes by how often they turn up:

1. Wrong compatible string — the device tree binds a driver for a sibling sensor in the same family.
2. Wrong I2C address — the reg property carries an 8-bit value where the bus wants 7-bit, or it points at a second chip on the module.
3. Wrong lane-mode overlay — the 4-lane support package for a module family whose variant you hold is 2-lane.
4. Physical layer — missing pull-ups or a logic-level mismatch, which usually destroy the read rather than bend it.

Read the failure signature straight off the ID value:

How do you test the I2C bus before blaming drivers?

Scan the bus, not the driver. With the camera stack stopped, a user-space scan at 100 kHz should show one ACK at the sensor's 7-bit address — commonly 0x10 or 0x1A on modules built on IMX sensors. The gap between where the module answers and where the driver looks tells the whole story in one minute. A second ACK may be the module's board EEPROM or, on a stereo module, the second sensor; shared-bus limits with multiple camera modules covers the conflicts that follow.

Camera documentation usually quotes an 8-bit address, and device trees take the 7-bit form. Convert deliberately:

A document that lists the sensor at 8-bit 0x34 is describing 7-bit 0x1A. Shift it, 0x34 >> 1 = 0x1A, then confirm the round trip: 0x1A << 1 = 0x34 write and 0x34 | 1 = 0x35 read. Copy 0x34 straight into the reg property and the driver probes 7-bit 0x34 — that is, 8-bit 0x68 write and 0x69 read — and finds a different chip or nothing at all. That one shift is a common root of wrong-ID reports on a second host.

Pull-ups belong on SDA and SCL, to the module's I/O rail, at 2.2-4.7 kOhm. Adapter boards that omit them leave the bus silent. When a scan returns nothing, probing SDA to cure an I2C bus startup failure walks the same fault down to the wire. When the scan works but the driver's own probe fails, camera I2C communication failure: diagnose sensor probe errors is the next stop.

What do you diff in the device tree sensor node?

Three properties decide the read: the compatible string, which selects the driver; the reg value, which sets the 7-bit I2C address; and the CSI endpoint's lane count, which must match the module wiring. Diff those three against the module vendor's reference device tree, in that order.

• compatible — it must name the exact sensor part on your flex, not the family. A sibling part number here is the classic cause of a plausible but wrong ID.
• reg — the 7-bit address on the correct I2C controller. Hosts number their buses differently, and a node that sits on one bus index in the reference design may need a different index on your carrier.
• The CSI endpoint — the data-lane count and the port the flex physically lands on. A 4-lane node on a 2-lane module will often bind and read the ID, then fall over at stream time.
• The overlay itself — read the boot log and confirm the host applied the overlay you edited, not an older copy kept in another boot slot.

After editing, reboot rather than waiting for a live rebind: most hosts apply camera overlays at boot only. If the driver package keeps overriding your node, device tree mismatch diagnosis for missing DTBs shows where the active tree really comes from, and device tree overlay CSI mapping troubleshooting covers the port-mapping half of the problem.

Can a 2-lane versus 4-lane mix-up change the sensor ID?

Indirectly, yes. 2-lane and 4-lane builds of one module family ship with different device tree overlays, and the overlay you load can point the host at a different sensor node — with a different driver and a different ID register — even though the sensor itself never changed. The ID travels over I2C, not over the data lanes, so the lane count cannot bend the value directly; the mix-up rides in with the support package. Variants of one family ship as separate packages: separate overlays, and sometimes separate sensor nodes when the family changed sensors between builds. Load the 4-lane package on a 2-lane module and the boot can still succeed while the overlay binds a node that was never meant for your flex.

The arithmetic is why the variants exist: the same pixel rate over half the lanes needs twice the per-lane clock. Four lanes at 450 Mbps per lane move 4 x 450 = 1,800 Mbps; over two lanes the same 1,800 Mbps means 900 Mbps per lane, with tighter timing margins on the flex. Match the overlay to the variant your module documentation names, and read MIPI camera lane bandwidth: what limits frame rate before trusting a boot that should not have worked.

What if the ID reads correctly but no frames arrive?

The ID proves the control path; frames need the data path too, and a pipeline whose media links were never formed registers the sensor while exposing no capture device. The pipeline needs a sensor entity linked to the CSI-2 receiver, the receiver linked to a capture node, with a format set on every pad in the chain. When a link is missing, the kernel registers the sensor and still creates no /dev/video capture node.

Print the media graph, create the missing links, set the format on the sensor pad, the receiver pads and the capture pad, then start streaming. If the graph is complete and frames still stall, the receiver side is the suspect: CSI camera carrier board compatibility: what to verify covers the receiver's own limits, and MIPI CSI camera no images: troubleshoot acquisition takes the pipeline apart pad by pad.

When is the camera module actually at fault?

Blame the module only when the fault follows it onto a known-good host, or when the bus answers nothing at all: a NAK on every address, or reads of 0x0000 and 0xFFFF, point at power, pull-ups, or the flex — not at device tree text. Two signatures indict hardware. First, the wrong or absent ID follows the module to the reference host: then the module, its adapter board or its flex is the part to replace. Second, the bus is silent everywhere, meaning no powered device on that segment.

Measure before replacing: the module's rails against its documentation, then SDA and SCL end to end for near-zero ohms, and the pull-ups on the adapter. A host that pulls the lines to 3.3 V against a 1.8 V sensor can hold the bus low permanently or degrade the part; that is a host-side design error, and it eats modules. Image sensor not detected: check camera module connections covers the full physical sweep. On the supply side, camera GPIO wiring: prevent damage and triage power faults covers the rails, and diagnosing missing sensor ACKs first applies the same NAK-first discipline on microcontroller hosts.

Should you switch to a USB3 or GigE board camera instead?

Switch when the host is a general-purpose computer you do not control at kernel level. USB3 and GigE board cameras enumerate through a standard interface, report their own identity, and remove this entire class of fault in exchange for a cable and a standard connector. Stay with MIPI when one module runs on one host the module vendor supports — it is the lowest-latency, cheapest link, and the fix above is usually a one-line device tree change. Switch when any of these hold:

• The deployment spans several host types, or the host kernel is not yours to change.
• The camera sits more than about 0.5 m from the host: a MIPI flex is realistically a short link, USB3 runs 3-5 m on a passive cable, and GigE reaches 100 m on Cat5e.
• Every camera must report a standard identity without a per-host driver.

A USB3 or GigE module reports its sensor identity in its standard device description, so no host device tree re-derives it. What GigE Vision guarantees for camera compatibility sets out exactly what that buys, and board level camera selection for embedded vision machines covers the wider choice. The board-level cameras range carries both interfaces, with camera cables to match.

The LS-BCM-0003 is a 3.1 MP USB3 board-level camera on the IMX252, a 1/1.8" global-shutter sensor at 120 fps, C-mount.

The MV-CB016-10GM-M-W is a 1.6 MP GigE board-level camera on the IMX296, mono, M12 mount, global shutter.

For the tightest builds, the LS-BCM-0060 is a 2.3 MP pen-style GigE camera and the LS-BCM-0061 is a 1.3 MP miniature GigE camera.

What order do you run the checks in?

Run it in this order, and it settles the question in about 30 minutes: known-good host, bus scan, device tree diff, overlay reload, then frames.

1. Move the module to the known-good host and confirm the correct ID. Five minutes, and it clears or convicts the camera.
2. Back on the failing host, stop the camera stack and scan the I2C bus at 100 kHz. Record every ACK address.
3. Read the ID register yourself, from user space, at the address that ACKs. A read that returns 0x0354 while the driver reports 0x0A56 convicts the binding, not the bus.
4. Diff the sensor node: compatible string, reg value, endpoint lane count, and whether the overlay you edited is the one that loaded.
5. Fix the node, reboot, and read the ID through the driver again.
6. With the ID correct, form the media links, set formats on every pad, and confirm frames.
7. Only after all six pass, treat the module as the suspect and measure its rails and flex.

Most cases end at step 4 or 5. If the fix points to a module the host can enumerate without a device tree, start from the camera finder or the system configurator, and bring the failing host's boot log and bus scan to the contact page — we will narrow the list with you. More embedded bring-up fixes sit under the systems topic.