CSI camera multiplexer not detected: bring up the bridge first

Two cameras work when each sits on the host's own CSI connector. Move them behind a CSI multiplexer board and i2cdetect goes quiet: no bridge address, no sensor addresses, and no probe line in dmesg. This walk-through is for engineers adding two or more MIPI CSI-2 cameras to one embedded host. It shows you how to tell within a couple of scans whether the multiplexer's own control chip enumerates, how to find the stage that kills the bus when it does not, and how to decide between a wiring fix, a driver fix and a different camera architecture.

What a CSI multiplexer must do before any camera works

A CSI multiplexer board sits between one CSI-2 receiver on the host and two or four camera connectors. Its control chip owns its own 7-bit I2C address on the host bus. The camera sensors hang on the downstream side, on channels the bridge opens and closes one at a time. The host driver brings up the bridge first, selects a channel, then probes the sensor behind it. Until the bridge's own address answers on the host bus, the sensors are electrically invisible: no overlay, lane count or pixel format reaches them, because no write does.

The gate exists because identical camera modules answer at the same address. Wire two of them to one bus and both ACK the first probe; the driver then configures one device that is physically two. That failure and its fixes are in Two image sensors with the same I2C address: bus options that work. A bus multiplexer of the TCA9548 class, set up as in TCA9548 I2C multiplexer for multiple MIPI cameras in the device tree, separates the downstream segments so each sensor answers only while its channel is open.

Separate segments are also why a working multi-camera rig still shows limits: the downstream sides share wires, and what that costs in probe order and timing is covered in Multiple camera modules on one host: shared bus limits.

Symptom and the four scan signatures

The case that lands here: both cameras probe cleanly on the host's own CSI connectors, so sensors, ribbons and sensor settings are proven good. Fit the multiplexer board and i2cdetect returns the same map as before — nothing new. That result is not a sensor problem, and it splits into four signatures:

Rows three and four have their own pages: Camera I2C communication failure: diagnose sensor probe errors, MIPI camera 2-lane vs 4-lane mode: why the sensor probe fails and Two camera overlays on one CSI port: probe failed, fix the config. The first row is this page's subject, and the worked example below turns it into a two-scan decision.

Worked example: two identical cameras, one adapter, nothing new in the scan

The rig: one embedded host with a single free CSI-2 connector, a two-channel multiplexer board, two identical camera modules. On the native connector each camera probes fine. Through the board, the scan shows no new address. Here is the same fault turned into arithmetic you can act on.

The inputs, with their sources (all counts are addresses):

• 7-bit addressing spans 128 addresses, 0x00 through 0x7F — from the I2C bus specification.
• The specification keeps 0x00–0x07 and 0x78–0x7F for its own purposes, 16 addresses in all, which is why i2cdetect marks those columns as skipped.
• The two camera modules are the same design, so both sensors answer at one address — probe one directly on the native connector and record it.
• The bridge chip answers at one address of its own, the value its address-select table prints for your board revision.

Address space is not the constraint: 112 usable against the 3 this rig needs leaves 109 spare, so an empty scan is absence, not congestion. That sets the decision threshold. Power up and scan once: exactly one new address, at the bridge's printed address, means the bridge is up and the sensor stage begins. Zero new addresses across two scans — after reseating the ribbon and measuring the board's supply — means bridge-level failure. No sensor-side edit can bring up a chip the host cannot see; stop configuring and change the hardware path.

The tied-bus version of the same sum: without a working bridge gating the channels, two identical sensors present 2 devices at 1 address, so the rig is 2 − 1 = 1 address short of independent control. The fix is a bridge that enumerates, not a cleverer probe.

Likely causes, most probable first

Order the causes by how often each one is still standing after the first two scans:

1. The OS image carries no driver for the bridge. Most likely when host, board and sensors were assembled from separate purchases rather than one tested kit. The signature is exactly this page's: cameras perfect on native ports, board totally silent. Look for the board in the OS's own hardware support — the vendor's supported-peripherals list or the device-tree overlay set. If the pairing is absent there, no configuration creates it. The matching logic before a purchase is in Board level camera sensor compatibility: match the host before you buy.
2. The bridge is unpowered or its enable pin is low. Some boards gate the control chip behind an enable line or a power switch the host must drive. Measure the board's supply pin against its sheet; 3.3 V is the common logic level on camera headers, but the sheet for the revision rules.
3. The wrong bus is being scanned. Camera connectors do not always land on the I2C bus number you assume. Scan every bus the host exposes; a healthy board answers on exactly one.
4. Another chip already holds the bridge's address. Scan without the board: if the printed address answers anyway, something else owns it. Move that device or restrap the board.
5. Ribbon and seating. A reversed or half-seated ribbon, or SDA and SCL swapped, shows up as the held-low scan where every address lights at once. Power down, reseat, check pin 1.
6. Pull-ups missing or doubled. With none, the bus floats and results differ between runs; with two sets fighting, edges slow and fast clocks misread. Flickering scans point here.

Test sequence: seven steps

1. Remove the multiplexer board. Scan every I2C bus the host exposes and write down what answers, bus by bus. This baseline is what nothing new is measured against.
2. Note which bus the CSI connector's I2C segment sits on — the boot log names the buses, and the camera connector is usually one of them but not always the one you expect.
3. Fit the board, power up, and scan all buses again. Compare against the baseline.
4. One new address at the bridge's printed address: the bridge is up. Open one channel and probe again; the selected sensor's address should now answer. From there, read the sensor's ID register over I2C as the next check, as in Camera sensor shows no image: check the chip ID over I2C first.
5. Nothing new: measure the board's supply and enable at its connector, against the sheet for your revision.
6. Still nothing: power down, reseat both ribbons, check pin-1 orientation, and rescan. An every-address-responds scan means this step found the fault.
7. A silent board after a supply check and a reseat: look for the board in the OS image's supported hardware. If it is not there and its vendor publishes no support for this host-board-sensor set, the combination is closed — go to the decision below.

The decision: fix downstream, buy the tested kit, or drop the mux

Bridge enumerates. You have a supported combination with a downstream fault: channel selection, sensor power or driver order. Work the sensor-side pages from the table above and keep the board. Cost so far: hours, not parts.

Bridge silent, no OS support. No overlay, lane count or reboot changes this; the parts were never tested together. Two honest paths. First, the multiplexer kit its vendor sells as one tested set for your host and sensor — kit vendors pair bridge, sensors and sync wiring, which is why those kits answer on the first scan. Second, the host's second native CSI port, if it has one; count the ports before buying any adapter, because a free port beats a switch.

Drop the shared CSI port. When frames must land at the same instant, cameras on their own USB3 or GigE links capture in parallel by construction and probe on separate buses — the multi-camera problem disappears instead of being managed. The board-level cameras category is the parts bin: compact modules that take M12 or C-mount lenses and connect over USB3 or GigE.

For two views over a single link with no multiplexer in the path, the binocular module LS-BCM-0043 carries both sensors on one USB3 connection.

One camera per link scales the same way: the MV-CB016-10GM-M-W pairs a 1.6 MP global-shutter mono sensor with GigE and an M12 mount, and the LS-BCM-0059 is a 1.0 MP mono GigE board camera with a split sensor that serves two views over one link.

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

On a production line rather than a board stack, area scan cameras are the same idea at industrial scale. The camera finder filters by interface, resolution and shutter type, and the camera step of the configurator assembles sensor, lens, cable and mount as one list.

So, per case: bridge up — fix downstream; bridge silent and the combination untested — tested kit or the second native port; simultaneous capture required — cameras on their own links.

When the usual advice is wrong

Add the sensor overlay and the camera will appear. An overlay binds a sensor driver to a CSI port; it cannot create a bridge chip that never ACKs. Settle the bridge with the scan first; overlay edits before that are noise.

A four-channel board gives four cameras at once. A plain CSI-2 switch drives one receiver, one stream at a time: you get sequential capture that you schedule in software. Simultaneous capture takes separate CSI ports, a pipeline with real virtual-channel multi-stream support, or cameras on their own links. Kits that advertise synchronized capture carry the sync hardware to do it — that is the difference you pay for, and the reason they enumerate and stream where a bare adapter does not.

i2cdetect proves the cameras are fine. The probe proves the I2C layer only. Power, clocks and driver binding still have to line up before the first frame; that later stage is MIPI sensor detected but streaming fails: power, clocks, device tree.

Checklist for the next multi-camera build

• Record the baseline scan before fitting anything. Nothing new is only a number against a baseline.
• Read the bridge's address and enable requirements from the sheet for your board revision before first power-up; revisions differ in both.
• Buy host, board and sensors as one tested set when schedule matters more than the parts list; matched kits answer on the first scan.
• Count the host's native CSI ports before buying an adapter; a free port beats a switch.
• Plan one active channel at a time on a plain switch and schedule capture around it.
• Move to cameras with their own USB3 or GigE links when frames must land together.
• Keep a spare board of the same revision in the drawer; a two-minute swap test splits a dead board from a wrong setup.

More bring-up walks of this kind sit under the systems topic. For the wider decision — interface, sensor format, shutter and mount as one choice — Board level camera selection for embedded vision machines covers the selection in one pass. When the decision lands on separate-link cameras, build the chain in the configurator above or reach the applications team through the contact page.