Camera sensor shows no image: check the chip ID over I2C first

You have power on the rails, an I2C probe that answers, and still not one frame out of the MIPI interface. That combination, a responsive sensor with no image, is the most common report from engineers bringing a raw image sensor up on a custom carrier board. The way out is one register read. Reading the chip ID first, before you write any init value, splits the fault in half: a correct readback proves the address, wiring, pull-ups and bus timing, which leaves missing initialization as the cause, while a NAK or a stuck value sends you to the electrical side. This guide gives the decision rule, the arithmetic behind it, the causes ordered by how often each turns out to be the culprit, and the bring-up order that follows.

Why a raw sensor stays silent until it is initialized

Raw CMOS image sensors leave the wafer in standby. Nothing about them streams out of the box: until software programs the register map, there is no PLL configuration, no MIPI lane timing, no output format and no stream-on command. Silence is the designed state, not a defect.

Two separate links matter, and they fail independently. The control link is I2C: your host reads and writes sensor registers through it. The data link is MIPI CSI-2: the sensor pushes pixel packets across it once it has been told to stream. A perfect control link with a silent data link is not a contradiction. It is what an uninitialized sensor looks like.

That is also why hunting for a complete register list is the wrong first move. The addresses are in the data sheet. What you need first is proof of which side of the fault you are on, and that proof costs one read.

Read the chip ID before you write anything

Every sensor family exposes one or two ID registers holding a constant the data sheet prints. Many parts place the ID at a fixed address pair such as 0x300A and 0x300B, but the locations and the expected value are per-sensor, so take both from your part's register map rather than from habit or from another project.

The read needs no initialization, which is what makes it the bisecting test. One transaction gives you a clean split:

• The ID matches the data sheet. Your 7-bit address, wiring, pull-up sizing and bus timing are all proven. The sensor will stream once initialized, so the fault is in the init sequence or the MIPI path.
• The read NAKs, or returns 0x00 or 0xFF on every register. Stop writing init tables. The fault is electrical: supply rails, master clock, address form, pull-ups or wiring.

A third outcome exists: a stable, repeatable value that differs from the data sheet. That usually means you are talking to a different sensor than you believe, or reading with the wrong register width, and both are worth an hour of checking before anything else. The guide on camera I2C communication failures and sensor probe errors covers the full probe sequence, and the wrong-I2C-probe checklist starts from exactly this mismatch.

Worked example: a raw sensor that answers at 0x60 with ID bytes 0x92 and 0x82

The case: a raw monochrome image sensor on a custom MIPI carrier. The host I2C controller runs standard mode. You have read two registers and need to know what the result proves.

Inputs, each with its source:

• 7-bit bus address 0x60 — sensor data sheet.
• ID high register 0x300A, ID low register 0x300B; this family uses 16-bit register addresses and 8-bit data — register map.
• Expected chip ID 0x9282 — data sheet.
• Bus clock 100 kHz — host I2C controller configuration.
• Your readback: 0x92 from 0x300A and 0x82 from 0x300B — console log.

Rule, in words: shift the high byte eight bits left, add the low byte, and compare the 16-bit result against the constant the data sheet prints. The cost of the check is the bits on the wire divided by the bus clock.

Arithmetic, the value first. 0x92 is 146, and 146 × 256 = 37,376. 0x82 is 130, and 37,376 + 130 = 37,506, which is 0x9282 in hex. That equals the data-sheet constant exactly.

Then the time. The read is one start, a device-address byte with the write bit, two register-address bytes, a repeated start, the device-address byte with the read bit, one data byte and a stop: five address-or-data bytes, each nine bits including its acknowledge slot, so 45 SCL cycles of payload. At 100 kHz each cycle lasts 1 / 100,000 Hz = 10 µs, and 45 × 10 µs = 450 µs. At 400 kHz fast mode the same 45 cycles take 45 × 2.5 µs = 112.5 µs.

Result and decision: the ID reassembles to 0x9282, so the address, wiring, pull-ups and bus timing are all proven. Do not spend another minute on the electrical side. The sensor is alive and listening, so the no-image cause is the missing register initialization, and the next action is the vendor's sequence for your mode. The threshold that would have flipped the decision: any NAK, a stuck 0x00 or 0xFF, or a repeatable but different value. And because the whole check finishes in under half a millisecond, it belongs in every boot, not just this bring-up.

The likely causes, in order, with the test for each

Work the list top down. The first test that fails names your fault, and every test above it has then been passed.

1. The sensor was never initialized. New board, correct ID read, no register sequence written: this is the cause most of the time. A raw sensor streams nothing until clock, PLL, MIPI lane timing, output format and stream-on are all in place. Fix: write the vendor sequence for your resolution, frame rate and lane count, in order.

2. Wrong address form or address strap. A single NAK at 0x60 is often convention, not a dead chip: tools that expect the 8-bit form want 0xC0 for a write and 0xC1 for a read of the same device. Check any address-select straps as well. Two identical sensors on one bus answer together at the shared address; the guide on shared I2C bus limits for multiple camera modules covers the separation options.

3. Power, pull-ups or master clock. NAKs on every address, or reads stuck at 0xFF, mean nothing is driving the bus low. Check the supply rails, the pull-up resistors on SDA and SCL, and the master clock, which many sensors need running before register access responds at all. The physical-link fix for I2C error -121 walks the wiring checks, and GPIO wiring and power-fault triage covers the supply side.

4. The receiver listens on the wrong mode. ID correct, init written, stream-on set, and still not one packet: that is the CSI side. The receiver must match the lane count, link frequency and data type that the sensor's mode table programs. Turn on the receiver's packet and error counters; counters that stay at zero mean the sensor transmits on lanes the receiver never opened. The 2-lane versus 4-lane mode guide explains that probe symptom, and the power, clocks and device-tree walkthrough covers the receiver configuration.

5. The sequence is partial, out of order, or stream-on never lands. A truncated table, writes issued before the clocks settle, or a missing final stream-on all end the same way: a configured chip that never starts. Read back the stream-on register and compare it with your write log; a mismatch means an earlier write went astray. The camera initialization start-sequence guide shows an order that works.

What is fixed in an init table, and what you tune

The register sequence keeps a stable shape for a given sensor: input clock and PLL setup, MIPI lane timing, output format, then stream control. Which registers you touch barely changes from one mode to the next. The values are the moving part: PLL dividers and lane timing come from the sensor's mode table, computed for your master clock, your lane count, your link frequency and your target resolution and frame rate. That is why one register dump cannot serve every host, and why a table that works on one carrier can be silent on yours.

Register width is part of the fixed structure, and it varies by family: the example sensor uses 16-bit addresses and 8-bit data, so every write carries two address bytes before the value. Confirm the width in the register map before you build any write helper.

Source the values from the sensor data sheet with its mode tables, from the sensor vendor's reference driver as shipped in your processor's board-support package, or from the camera module vendor's documentation and support channel.

Make the ID read your first boot check

Log the chip-ID read at every power-on and assert on the expected value. At under half a millisecond the cost is nothing. After a board revision, a cable swap or a firmware update, that one logged line tells you whether the control link is still intact, before an hour gets spent re-checking a receiver configuration that was never the problem. Keep the expected constant beside the driver code, so a sensor revision swap shows up as a clean mismatch instead of as a mystery.

When to skip raw bring-up

Raw-sensor bring-up earns its keep when you need a custom form factor or a cost-optimized design at volume. When the schedule is the constraint, an integrated module hands the problem to a driver that already exists: the vendor's code writes the whole register sequence, and you work at the interface level. Both board-level cameras and area scan cameras arrive initialized. The LS-BCM-0003 pairs a global shutter with USB3 at 120 fps, the LS-BCM-0020 covers 6.3 MP at 18 fps over GigE, and the MV-CB016-10GM-M-W keeps the footprint small at 1.6 MP on an M12 mount.

Choose by shutter type for motion, by mount for the optics you already own, and by interface for the host you have.

Stuck after a clean ID read with still no frames? Send the sensor part number, your host interface and lane count through the contact page; include the actual readback values and the fault usually names itself. To compare integrated options instead, start the camera configurator or filter the camera finder by sensor, shutter and interface, and the systems guides hub collects the rest of the bring-up walkthroughs.