CSI camera powers up but no image: I2C errors on Jetson

Your CSI camera clicks its IR-CUT filter at boot, the driver binds, v4l2-ctl --list-devices lists the node — and every capture comes back empty. The kernel log fills with power complaints and failed register writes, and a second driver reinstall changes nothing. This is the partial bring-up case: the module is alive, the software stack is loaded, and the sensor never gets programmed. What follows walks the evidence in order — what the click does and does not prove, which dmesg lines put the fault on the I2C wiring rather than the driver, and the test sequence that separates cable from connector from module. The numbers come from a real Xavier NX case on L4T 35.6.2, kernel 5.10.216-tegra, where the same module streamed on a Raspberry Pi and an earlier unit streamed on the same Jetson.

The click proves one rail, nothing more

A MIPI CSI module is not one load. It brings up several power domains in a fixed order — sensor core, I/O, analog — and only then may the host write the first register. The IR-CUT filter sits ahead of all of that: it is a mechanical shutter switched by module-level circuitry, which is why you hear it before anything else happens.

The click therefore tells you the module supply and the filter drive are present. It says nothing about the sensor's digital core answering on I2C, and nothing about the MIPI lanes carrying data. Treat it as a power-OK lamp for one rail.

That is also why the driver can log camera not powered after an audible click: the driver's notion of powered comes out of its power-up sequence and register access, and when both fail, the sensor reads as unpowered with the filter rail clearly up. If your symptom is the opposite — the module never appears at all — start with IMX477 not detected on Jetson Orin Nano: CSI bring-up checks instead.

Three message families in the log

Pin the platform, then pull the filtered logs:

uname -a
cat /etc/nv_tegra_release
dmesg | grep -i imx477
dmesg | grep -i i2c
v4l2-ctl --list-devices
lsmod

Family one is power:

imx477 10-001a: camera not powered
imx477 10-001a: no power
imx477 10-001a: failed to power on

These lines are the driver's view of its own power-up sequence, not a voltmeter reading.

Family two is register writes: imx477 10-001a: imx477_write_reg: i2c write failed, 0x104 = 1. On this sensor, 0x104 is the group-hold control register, and the driver sets it while loading a mode — resolution, frame rate, exposure banks. If that write never lands, the mode never loads and the sensor has nothing to send. The MIPI lanes never get the chance to fail.

Family three is the controller itself: arbitration lost, together with a failed clock-rate change, reported by the Tegra I2C controller. These lines come from below the sensor driver, at the signaling layer, and they are the ones that name the real fault.

Read one detail before acting: /dev/video0 is vi-output, imx477 9-001a (platform:tegra-capture-vi:0), the failures land on 10-001a, and the sensor answers at address 0x1a on both adapters 9 and 10. Two instances means the device tree describes the sensor on two buses. Confirm which node your capture pipeline opens before you chase either set of errors.

Why arbitration lost clears the driver

Arbitration lost has one meaning: the controller released the SDA line and read it low when it expected high. Either something else is holding the bus, or the rising edge did not arrive in time and the controller sampled a transition. Both are electrical conditions — cable capacitance, pull-up strength, contact resistance. No driver above the controller can synthesize that error, and no reinstall removes it.

The software side checks out completely here: lsmod shows nv_imx477 loaded, the /dev/video0 node exists, and the vendor package version 5.10.216-tegra-35.6.0-20250314171843 matches the running kernel 5.10.216-tegra. Two reinstalls reproduced the same log both times. Add the cross-evidence: the module streams on a Raspberry Pi, and an earlier unit of the same sensor streamed on this Jetson. Module, driver and host have each produced a working stream on their own — what sits between them is the ribbon and two connectors.

The mirror-image failure probes cleanly and then times out on frames: I2C fine, MIPI broken. Sensor detected but frames time out: separating I2C from MIPI failures works that split; this log puts you on the I2C side from the first line.

Worked example: 10 kΩ pull-ups on a 300 pF CSI ribbon

Inputs, with their sources. Take module pull-ups of 10 kΩ, a common value on camera carrier boards. Take a bus capacitance of 300 pF: a 300 mm ribbon, two connectors, and the pin and trace capacitance that comes with them. The limits come from the I²C-bus specification, UM10204: standard mode at 100 kbit/s allows a rise time of 1000 ns, fast mode at 400 kbit/s allows 300 ns.

Work the numbers. 0.8473 × 10,000 Ω × 300 pF = 2.54 µs — call it 2.5 µs. That is two and a half times over the 1 µs standard-mode limit and more than eight times over the 300 ns fast-mode limit. A controller on this bus sees edges it cannot place in time, and it reports exactly what this case logged: arbitration lost, a failed clock-rate change, and register writes such as 0x104 that never complete.

The fix, in numbers. To meet fast mode on 300 pF, the pull-up may be at most 300 ns / (0.8473 × 300 pF) = 1.18 kΩ, so fit 1.2 kΩ. Check that the value is legal: 3.3 V / 1.2 kΩ = 2.75 mA of sink current, inside the 3 mA the specification permits, and above the floor of (3.3 V − 0.4 V) / 3 mA = 970 Ω. Or attack the capacitance instead: at 100 pF, the same 10 kΩ gives 0.8473 × 10,000 Ω × 100 pF ≈ 850 ns — legal for standard mode, still too slow for fast mode.

Decision: hold rise time under 1 µs and the bus runs 100 kbit/s; hold it under 300 ns and it runs 400 kbit/s. You rarely get to rework pull-ups on a sealed module, so the lever you own is capacitance — the shortest ribbon that reaches, in good condition. This is also why one module streams on one host and logs errors on another: the bus that meets its limit works, the bus that misses it does not.

Test in this order: cable, connector, module

1. Replace the ribbon; do not only reseat it. Reseating the same cable several times with no change is not a test, because a creased conductor or a torn contact at the stiffener survives reseat after reseat. Fit a new cable, keep it the shortest length that reaches, and confirm the contact orientation at both ends the way the module's drawing shows. The cable is the cheapest part in the chain, so it goes first.
2. Inspect the host connector. An earlier module worked on this board, so the connector has mating cycles behind it. Under magnification, look for a lowered or bent contact: a pin that no longer wipes its pad gives exactly this signature — probing, an ACK at 0x1a, then failed write bursts. If the carrier exposes a second CSI connector, move the ribbon to it; errors that follow the connector condemn the connector.
3. Cross-check with any other CSI module you can borrow. The Raspberry Pi result proves the sensor works under a different host controller; it does not prove this module meets this host's timing. When another module streams on the Jetson and this one does not, the module goes back.
4. Then, and only then, read software again — and there is nothing left to find: the driver binds, the node exists, the version matches.

When dmesg will not localize the fault further, the host's CSI trace log goes one layer deeper; troubleshooting Jetson AGX Orin CSI trace log errors walks that log end to end.

The escape hatch: a standard interface instead of CSI lanes

CSI earns its keep at production volume and in tight mechanical envelopes. For one or two cameras on an embedded host, a USB3 or GigE board-level camera turns a bring-up problem into a cabling problem: standard connectors, standard drivers, and faults you can see with ordinary tools. When the schedule has already lost a week, take that trade. Full-size area scan cameras cover the same ground when the mounting allows it, and the camera finder filters by interface, mount and shutter.

For a sensor swap off the CSI bus, the LS-BCM-0003 is a 3.1 MP USB3 board-level camera, IMX252, 1/1.8" global shutter, 120 fps.

To integrate bare boards: the MV-CB060-10UM-B is a 6 MP USB3 board camera on the IMX178, and the LS-BCM-0020 is a 6.3 MP GigE board camera, IMX178, 1/1.8" rolling shutter, 18 fps. For USB3 runs, the LS-CBL-0219 is a 3 m USB3.0 camera cable rated for drag-chain use; for GigE, choose from the camera cables range.

Before a module goes on a production line, the board camera evaluation checklist for inspection systems lists the checks that catch this class of fault early.

When the usual answer is wrong

"Reinstall the driver" is the default first move, and here it is the wrong one: the package matched the running kernel exactly, and two reinstalls reproduced byte-identical errors. Reinstalls cure version mismatches after an L4T upgrade, not signaling. If the driver never loads at all, that is a different fault, covered in enable IMX477 on JetPack 6 with jetson-io when JP5 guides fail.

"It works on the Pi, so the Jetson is broken" is half right. The host is implicated — through its connector, its pull-up network and its controller timing, not through its software. And "a previous unit worked here" points at the same link from the other side: connectors accumulate mating cycles, and a module and its host must be tuned as a pair, as MIPI CSI camera bring-up: sensor and host tuning must match as a pair argues.

"No image" is not one fault. A node that never appears is a detection problem; see MIPI camera not detected: I2C bus and device tree checks. A stream that runs in setup and greys out at runtime is another layer entirely: camera works in setup but grey image at runtime. Keep the layers separate and the log tells you which one you are in.

Prevention checklist

• Match the carrier's CSI pinout against the module before first power-on; checking Jetson Orin Nano CSI pinout compatibility takes minutes and saves the most expensive hour of the project.
• Order a spare ribbon with the module. It is the first part you will swap and the last one anyone stocks.
• Strain-relieve the ribbon at both ends so the connector never carries cable weight or vibration.
• Keep the run as short as it can be; rise time is capacitance, and capacitance is length.
• Save a clean dmesg | grep -i imx477 capture the day the system works. Diffed against a failing log, it localizes the fault faster than any single line.

If you want a second pair of eyes on a failing log, bring it to the contact page. The rest of the bring-up chain lives on the cameras topic page.