Sensor not detected behind a serializer: power and reset GPIO checks

You have a camera module whose serializer answers on the I2C bus while the image sensor behind it never appears. The overlay is applied, the pipeline topology prints, and the sensor node is still missing. On most modules the cause is not the driver: the sensor's power-enable and reset lines are wired to GPIO outputs on the serializer, and nothing has configured those outputs yet. The fast path is schematic, registers, device tree: trace the two lines, assert them by hand with i2c-tools to prove the hardware, then move the proven sequence into the device tree.

Why the sensor stays invisible while the serializer answers

A serializer-deserializer pair moves camera data over a serial link and carries control traffic the other way. The link powers the module side, so the serializer chip is alive before anything else happens, and its own bus address answers a scan. The sensor sits on the far side of that chip, on a short I2C segment local to the module, and the deserializer can forward host traffic into that segment once forwarding is enabled.

Power is the catch. The sensor's core, I/O and analog rails come from a regulator on the module, and the enable pin of that regulator — plus the sensor's reset line — runs to pins the serializer uses as GPIO outputs. Until those outputs are configured and driven in order, the sensor is unpowered or held in reset, and no scan finds it. The same serializer outputs that route trigger signals in GPIO trigger routing on a serializer board: one input, six cameras are the ones that sequence a sensor's power here.

Trace first: what the schematic must tell you

Pull the module schematic and the sensor data sheet, and write down four things before you touch a register:

1. Which pins. The serializer port pins that drive the regulator enable, the sensor power-enable and the sensor reset. Register maps list every GPIO bit; the schematic names the two or three that matter on your board.
2. The idle state. Pull resistors set the state before any GPIO drive. A 10 kΩ pull to ground, for example, holds an active-low reset asserted until a driver releases it.
3. The rails. Most modern sensors run three supplies — around 1.2 V core, 1.8 V I/O and roughly 3 V analog. Note which one the meter must see before reset release counts.
4. The addresses. The sensor's I2C address and its strap options, plus any alias the serializer's mapping registers might remap it to.

Then read the power-sequence section of the sensor data sheet. It prints the order — rails stable before reset release — with the minimum delays in a timing diagram. Those printed minimums govern the script in the next section.

Prove the hardware: assert the lines with i2c-tools

1. Find the serializer. Scan the host bus with i2cdetect -y 2 (bus 2 as an example; yours differs). The serializer must show up at its address — it answers with no forwarding configured, because the link powers it.
2. Configure the outputs. In the serializer register map, find the GPIO block: the direction register that turns a pin into an output and the output register that drives it. Write them with i2cset, using the register numbers and bit positions the map prints.
3. Sequence. Drive the regulator enable first and wait for the rails — a 5 ms script delay clears data-sheet minimums that run shorter. Release reset second, to its inactive level. Order matters more than length: rails first, reset released last.
4. Open forwarding and rescan. Set the register the map prints for I2C forwarding into the remote segment, then scan again for the sensor's address.

Worked example: predict the address the scan must show. Sensor data sheets print I2C addresses in 8-bit form — the write address — while the bus and i2cdetect use 7-bit:

If the sheet prints 0x34, the cell at row 1, column a of the scan must read 1a after the poke. The 7-bit space runs 0x00–0x7F: 128 addresses, of which 0x00–0x07 and 0x78–0x7F are reserved, leaving 112 usable. The timings also work out: one 3-byte register write is 1 start bit + 3 × (8 data bits + 1 ack) + 1 stop = 30 bits, and 30 bits at 10 μs/bit (a 100 kHz bus) is 0.3 ms. A bench script of four writes, two 5 ms waits and a full scan therefore runs 4 × 0.3 + 10 + 34 ≈ 45 ms end to end — quick enough to loop while you meter the rails.

If the serializer's address-mapping registers remap the remote sensor to an alias on the host bus, the sensor answers at the alias on a host-side scan and only at its native address through the forwarded segment. Scan both windows before you conclude silence.

Make it permanent: device tree GPIO and regulator bindings

Register state dies at the next reset, so the proven sequence moves into the device tree, where it runs at every boot before the sensor driver probes. Three edits carry it:

• the sensor node gains the GPIO entries that name the GPIO controller, pin index and active level for its reset and power-down lines;
• the regulator nodes that make the sensor rails gain their enable GPIOs, so the kernel raises rails in the order the data sheet's timing diagram shows;
• the serializer node gains the pin configuration for the outputs you proved by hand.

Match the overlay to the module you actually have. An overlay borrowed from a module with similar wiring is the classic reason a complete driver stack still leaves the sensor dark: its reset entry points at a pin that is a regulator enable on your board, and nothing sequences the real line.

After boot, check three things: the kernel log shows the sensor driver probing without error; the media graph, printed with media-ctl, chains the sensor subdev between the serializer and the bridge; the scan now reports UU at the sensor address because your driver owns it. A failed probe sends you to Sensor probes but no video node: fix the devicetree chain, a media device with no capture node to media0 with no video0 device node: the sensor driver never probed, and a sensor detected but never streaming to MIPI sensor detected but streaming fails: power, clocks, device tree.

Sensor still silent: the remaining causes in order

1. Rails never rise. Force the GPIO outputs again and meter at the sensor's pins, not the regulator's output. Zero volts there puts the fault in the enable path, the regulator or a joint; a rail reading near zero ohms to ground is a short. Fix the hardware or replace the module — Board level camera replacement when a sensor goes end of line covers choosing the successor.
2. Reset held at the wrong level. Check the active level against the data sheet and the pull resistors, stretch the hold to 10 ms and rescan.
3. Address mix-up. Convert the 8-bit address, scan both the forwarded window and any alias, and rule out a second device at the same address — Two image sensors with the same I2C address: bus options that work sorts the bus options.
4. Forwarding never opened. Until forwarding is on, the host-side scan shows only the serializer. Open it, then scan the remote segment with the sensor powered — in that order.
5. Link hardware. A half-seated ribbon or a damaged lead between module halves looks exactly like a dead sensor. Reseat, then measure. If the sensor answers but frames time out, the fault has moved to the data path — Sensor detected but frames time out: separating I2C from MIPI failures is the diagnostic to follow.

Wiring the power-enable and reset lines to a remote head

When the module lives away from the host board, those GPIO lines, the trigger line and the module supply all cross the machine as cable. Treat them as signal wiring: shielded, one ground return per cable, drag-chain rated where the harness moves, routed away from motor leads. For a head with an M8 connector, the LS-CBL-0300 carries the supply and the control cores together in one shielded, 7 m, drag-chain-rated lead.

For a head with a 12-pin I/O connector, the LS-CBL-0211 bundles the control lines with the supply in one 5 m harness instead of a second unshielded lead.

Drive levels get noisier down a cable, so check the pull-ups and assert levels at the far end, not just at the driver. Camera GPIO wiring: prevent damage and triage power faults walks the electrical side of driving and protecting these lines, and Board-level camera ribbon cable replacement: latch and length limits covers the short ribbon inside a two-board module.

The decision for each case

• Serializer answers, sensor does not, pins untraced: the schematic first. Register maps list dozens of GPIO bits; the schematic names the two that count, and it decides which registers you write.
• Pins traced, sensor appears after a manual poke: the hardware is proven. Write the sequence into the device tree once and stop poking on every boot.
• Full poke sequence done, still no address: meter the rails at the sensor pins. No rails, or a rail shorted to ground, is hardware — replace the module. Rails present but silent is an address or forwarding problem — scan both windows and check the alias.
• Sensor present, frames absent: power sequencing is solved; follow the I2C-versus-data-path split above.

If the module turns out dead, the board-level cameras range and the camera finder are where a replacement comes from, and the camera step of the configurator narrows the field by sensor and interface; harnesses and I/O cable live under cables. More fault-finding guides sit on the systems topic page, and if a build is still stuck, contact us with the module, the schematic page and the scan output.