GMSL LOCK LED not lighting: I2C works but no video arrives

A GMSL camera kit that answers on I2C but never lights its LOCK LED is not a failed sensor in most cases. The control side-channel and the multi-gigabit video channel are separate paths inside the same serializer-to-deserializer pair, and one can run while the other is dead. This guide walks the failure in the order that finds it fastest: what LOCK actually reports, the 12 V supply under load, the coax path, a second camera competing for the capture pipeline, and reading lock status from your own code. Every step uses the commands, log lines and voltages from a real bring-up that ended in a working capture, and the final section covers the point at which a GMSL kit should give way to an industrial interface for a production machine.

Why does I2C answer while the LOCK LED stays dark?

Because the control channel and the video channel are two independent paths: the deserializer can expose the remote sensor at its 0x10 address on I2C while the high-speed serializer-to-deserializer link that must carry the frames never locks, so capture times out with no data.

In the bring-up behind this guide, the host registered the sensor cleanly. dmesg showed both the subdevice and the capture binding:

rp1-cfe 1f00128000.csi: found subdevice.../imx219@10
rp1-cfe 1f00128000.csi: Using sensor imx219 11-0010 for capture

i2cdetect confirmed the address at 0x10. The failure showed up exactly one layer later. The capture attempt ended with Camera frontend has timed out! after Dequeue timer of 1000000.00us has expired! — the pipeline waited 1,000,000 µs, a full second, and received zero frames.

That split is documented SerDes behaviour. The control side-channel lets a host program the serializer, the deserializer and the remote sensor's registers independently of video, and lock is reported separately by a LOCK pin and a LOCKED status bit on both chips. Detection without data is exactly what a dead video path over a live control path looks like.

The two paths also differ enormously in speed, which is why the fast one fails while the slow one lives. Assume full-resolution output, 10-bit, 30 frames/s:

At 100 kbit/s the I2C side-channel moves one bit every 10 µs, so a 3-byte register write takes 27 bits × 10 µs = 270 µs. The video channel must carry 2.42 Gbit/s — about 24,000× faster, more than four orders of magnitude. Bit depth and frame rate scale that linearly: 12-bit output raises it by 20%, and 60 frames/s doubles it. A path that answers a 270 µs probe tells you nothing about a path carrying 2.42 Gbit/s.

Three nearby failures look similar and are not this one. When the host never sees the device at all — no sensor line in dmesg, no address in i2cdetect — that is one stage earlier, covered in GMSL camera not detected: capture-card power and cabling. If i2cdetect shows UU where you expect 10, a driver has claimed the address; i2cdetect UU and I2C wiring guide walks that case. And the same probed-but-silent signature on a plain CSI sensor is worked through in MIPI sensor detected but streaming fails: power, clocks, device tree.

What does the LOCK LED actually report?

It reports physical link lock: the SerDes documentation defines a LOCK pin and a LOCKED status bit that go high on both the serializer and the deserializer once the link is established, so a dark LED means the video link itself never came up — not that the sensor is broken.

The ERROR LED adds nothing here: it lights only on faults the firmware decides to flag, so dark-plus-dark is the normal signature of a link that never got far enough to complain. Read the pair as power-or-path first, sensor last.

Work the causes in the order below; the first three are two-minute tests, and they cover what this signature actually produces:

Reading a hardware lock indicator before drawing software conclusions is standard isolation practice everywhere in industrial debugging — the same logic used when a servo drive's port link-activity LED stays off while the rest of the device communicates.

Is the deserializer's 12 V supply good under load?

A plugged-in barrel jack proves nothing, so measure 12 V DC on the board side of the connector while the link is trying to lock: a dead adapter, a swapped centre-negative tip or a supply that collapses under load all leave I2C alive and LOCK dark.

Run it as four steps:

1. Meter on DC volts, black probe on the sleeve (ground), red on the centre pin — at the board side of the connector, not at the adapter.
2. Power the board and start a capture attempt, so the link is actively trying to lock while you read.
3. Read the voltage. Steady at 12 V within a couple of percent is healthy. Zero volts means a dead adapter, a broken cord or a swapped polarity tip. A reading that sags or hunts the moment capture starts means the supply cannot deliver the current.
4. If the camera head takes its own feed, measure that input the same way.

In the case behind this guide the jack was connected and the rail held, so this check passed — it stays first in the order because it is the only cause that produces this exact signature while costing two minutes to eliminate.

If the probe stops answering altogether — an I2C error instead of an address — you are earlier in the chain than the failure traced here; fixing the physical link behind an I2C sensor probe error covers that stage.

Should you suspect the coax when I2C still works?

Yes, and test it before theorising: the video channel runs more than four orders of magnitude faster than the control channel, so a coax assembly that passes I2C can still be dead at video rates, and a spare-cable swap settles it in two minutes.

Reseat both ends first. The traced case did that with no change, which is itself useful information: it moves suspicion from the connectors to the cable or beyond. Then fit the kit's spare coax and watch the LED at power-up. LOCK coming on with the spare closes the case; label the old assembly as marginal and take it out of service.

Improvised extensions are the classic self-inflicted wound. A jumper built with different impedance reflects energy at gigabit rates, the eye at the receiver never closes, and the lock never comes up — while the low-rate control side keeps working and i2cdetect stays clean. Use the cable type and length the kit specifies.

Swap-first is also the discipline that clears a powered USB camera that stops being detected after a cable swap: change the physical layer before the software.

Why does a second camera on another port block the lock?

In the traced bring-up this was the cause: a second camera module on the host's other capture port kept the link from locking, and with that module detached the capture command that had timed out on every run completed on the first try.

The mechanism, as far as the logs reach: both sensor drivers register against one capture frontend, and with two attached the SerDes bridge never settled into a working streaming configuration, so the link stayed unlocked while the frontend waited on frames that would never arrive. The register-level interaction is not visible in dmesg, and it does not need to be — the A/B test is unambiguous.

The boot overlay (dtoverlay=imx219,cam1 in /boot/firmware/config.txt) was already correct in this case; detection proved that. Resist the urge to edit configuration first and run the isolation instead:

1. Power the host down fully.
2. Disconnect the second camera module from its port.
3. Boot and confirm the GMSL sensor still registers — the same two rp1-cfe lines as before.
4. Rerun the capture with the preview path removed:

rpicam-still -t 100 --mode 640:480:10BGGR --raw -o gmsl_check.dng -n

The -n flag skips the preview window, which takes the display out of the test.

5. Confirm the LOCK LED lights and the file is written.

If the second sensor shares the GMSL link's control bus rather than sitting on another port, address collision becomes its own failure — two image sensors with the same I2C address covers the bus options that work. A sensor that registers but produces no video node at all points at the boot configuration chain instead of the link; sensor probes but no video node walks that chain.

How do you read link lock from your code?

Poll the LOCKED status bit in the deserializer's register map over the control bus: the SerDes documentation defines it as the software view of the LOCK pin, and bring-up tooling treats missing lock as a nonzero exit, so your code gates on the same signal the LED shows.

The bit's address comes from your chip's register map and the kit's driver — read it there, never from guesswork. For hot-replug detection, poll at 5-10 Hz; that catches a disconnect-and-reconnect within a couple of hundred milliseconds at negligible control-bus load. On a falling edge, stop the stream and tear the pipeline down; on a rising edge, re-run the serializer's initialization and restart. Where the driver exposes no lock event, polling is the mechanism — there is nothing to subscribe to.

If LOCK reads high but the pipeline still fails to start, the link is no longer the suspect; camera capture pipeline startup failure: isolate the cause gives the stage-by-stage probe. When re-initialization must happen without dropping a running stream, apply camera settings while streaming shows the non-stalling pattern. The systems topic page gathers the diagnostics around this layer.

What stops this from coming back on the next bring-up?

Three habits cover every cause in the table above: bring the link up with one sensor attached, prove the 12 V rail under load before touching software, and gate streaming on the LOCKED bit instead of on the sensor's I2C address answering.

• One sensor until lock. Attach the second camera only after the first locks and streams; the contention above hid for days because both modules looked innocent.
• Supply under load. A two-minute meter check at the board eliminates the cause most likely to mimic a dead link.
• Swap, then label. After any coax swap that changes behaviour, the removed assembly leaves the bench; a marginal cable always returns.
• Lock before streaming. Read the LOCKED bit at startup and refuse to open the pipeline while it reads low; that turns a silent one-second timeout into an explicit, logged error.
• Log lock transitions. A timestamped falling edge is the difference between debugging a replug and guessing that one happened.

When is a GMSL kit the wrong interface for the machine?

When the prototype has to become a production machine: move capture to an interface with long-term driver support and cabling built to industrial lengths — GigE for 100 m runs, USB3 for short links, CoaXPress for multi-gigabit per camera — and leave the GMSL kit on the bench.

GMSL SerDes kits are development parts: the documentation lives in chip register maps, driver support follows the kit vendor's release cycle, and neither the coax assembly nor lock behaviour is specified the way an industrial camera interface is. For production, spec the capture side by interface:

All 3 share: Humidity 10% RH to 95% RH (no condensation). Values as printed in each product's data sheet; open a part for its drawing and full specifications.

For several high-bandwidth cameras on one host, the MV-GX1008 Octo CXP-6 frame grabber is the CoaXPress entry point, and the frame grabbers category carries the full interface range — GigE, 10GigE, CoaXPress, Camera Link and XoFLink. Pair the card with a global-shutter area scan camera from the camera finder, and order camera data cables in the lengths the machine needs: high-flex GigE and USB3 assemblies run from 3 m to beyond 20 m, while a standard GigE run reaches 100 m under IEEE 802.3. These cards are PCIe parts, so the host side is a PC-class controller — an industrial mini PC built for PCIe capture cards is the usual pairing.

If the interface choice is not obvious, send the camera count, resolution and frame rate through the contact page. The recommendation comes back with the numbers behind it, and expert support is included with every order.