FPD-Link III camera bring-up when no board guide exists

You have a serialized camera kit: a small sensor board, a serializer, a length of coax and a deserializer card that presents the video to a processor board's CSI-2 input. The vendor validated the kit on one reference board and wrote the manual for that board alone. Now you are moving it to a different board from the same silicon family, the manual's steps no longer match your hardware, and bring-up fails somewhere underneath them. The fault will sit in one of four layers — power, the coax link, I2C addressing, or the device tree — and there is a fixed order that finds it fastest. This page gives that order, the one measurement that clears each layer, and the point at which changing the camera is the faster decision.

The order: power, link, address, device tree

Work hardware-first. A driver cannot power a serializer whose rail never came up, and a device tree cannot address a sensor the bus cannot see. Each layer has one measurement and one pass test. Stop at the first layer that fails, fix it, and re-test from the top: a fault in a low layer impersonates every layer above it.

The first two layers cost you a multimeter and about ten minutes each. Only the fourth is open-ended, which is why it comes last.

Layer 1: a kit that will not even turn on is a power problem

The camera side of an FPD-Link III kit draws its power over the coax — power over coax, PoC — from the deserializer board, and evaluation kits typically feed that rail from 12 V. A dead kit therefore has exactly three suspects: the carrier's feed to the deserializer board, the coax and its connectors, and the camera-side board itself. Same-family processor boards one letter apart in the name can route the rail to a different header pin and invert the enable line, so a kit that is alive on the reference board and dead on yours is telling you something about the carrier, not about software.

1. Measure the deserializer board's input rail at its power connector.
2. Measure the same rail at the camera end of the coax, connector mated. This second number is the one that matters: it includes the carrier feed, the connector and the cable.
3. Compare both readings against the input range in the kit's power specification.

The arithmetic for what a healthy coax costs you:

Worked example: a 5 m lead of the thin coax shipped with camera kits runs about 0.1 Ω per metre per conductor, so R_loop = 2 × 5 × 0.1 = 1.0 Ω. A camera side drawing 150 mA drops 0.15 A × 1.0 Ω = 0.15 V, and a 12 V rail arrives as about 11.9 V. That is the real message of the measurement: a mated, healthy coax barely dents a 12 V PoC feed. If the far end reads zero while the input reads nominal, the rail never reaches the coax — header pin, enable line or fuse — and no driver, tree or script will change that.

Layer 2: link lock divides hardware from software

Lock means the deserializer has recovered clock and data from the serial stream. It depends on the coax, the connectors and the mode settings of the serializer/deserializer pair — on nothing the processor runs. That makes the lock bit the cleanest divider in the whole job: locked with no image points at software; no lock points at cable or configuration, and no amount of device-tree editing will move it.

Read the deserializer's lock and error-status registers from the host over I2C. SerDes register maps are reachable over I2C alone; a UART header on a carrier board serves that board's controller, not the serializer's register space. Some deserializer boards add a lock LED — treat it as a hint and trust the register. Lock asserts well inside a second of power-up. A bit that flickers, or that drops when you flex the lead, is a connector problem: reseat before you reconfigure.

Camera serializers of this class push one coax at up to 4.16 Gbps. For first bring-up, keep the lead to a metre or two with no mid-span adapters, and mount both boards so the coax does not move while you measure — a bracket from the camera stands range holds a small board as steadily as it holds a camera. The same power-then-link order applies when a GMSL camera is not detected; the two interface families fail in the same places.

Layer 3: locked link, invisible sensor — check the I2C alias

The host's I2C bus reaches the deserializer at its own address. The sensor, on the far side of the link, appears either at its native 7-bit address — address pass-through — or at an alias address the deserializer translates across the link. Kits bring the SerDes up with a start-up script that programs those aliases; on a new board that script may never run, and the sensor goes quiet even though the link is locked.

Two failures, one test. Sweep the bus (i2cdetect on Linux) and count ACKs. One ACK, for the deserializer only: the alias or the forwarding path is not programmed. Two ACKs at the same address: the sensor's native address collides with another device on your carrier's bus, and both devices corrupt every transaction aimed at that address. The fix in both cases is the same order — program the deserializer's alias from the host first, then load the sensor driver pointed at the alias.

If the sweep shows nothing at all, read the deserializer's own address against its strapping before assuming the board is dead: diagnosing I2C probe errors starts there, and shared-bus limits come into play once several modules sit on one host.

Layer 4: port the node names, not the tree file

The manual's device-tree snippet names the reference board's receiver node, its endpoint and its camera node. On your board, the CSI-2 receiver instance, the lane order, the reference clocks and the enable GPIOs differ, so pasting that snippet into your tree binds nothing. Work the other way round: take your board's own tree, attach the camera node under your board's receiver endpoint, and give the driver the alias address from the layer above.

Check in this order: the driver's probe line in the boot log, then the media topology listing the sensor, then the first frame through your capture pipeline. A probe that succeeds and a pipeline that stays empty is an endpoint problem — lane mapping or clock — and CSI mapping troubleshooting covers exactly that split. If the driver never even attempts a probe, start with missing device-tree blobs. Modules that take both serialized interfaces have capture-side settings of their own, and configuring GMSL and FPD-Link III camera access on an embedded module walks through them. For the wider integration path, isolating embedded camera bring-up failures maps the same layers onto a full design.

When to stop porting and change the camera

Put numbers on the effort. Power and link checks: half a day with a meter. Addressing: an hour or two. The device-tree port on a board nobody has validated: open-ended — this is the layer where kits stall for weeks waiting on a port that does not exist yet. So set the tripwire before you start: if layers one to three pass, no validated port covers your board, and the machine ships inside two weeks, cap layer 4 at three working days. Then put a standard-interface board camera behind your optics, ship the machine, and return to the SerDes kit when the port lands.

The trade is distance and wiring, not image quality. A single coax runs 10-15 m at full rate with the specified cable; GigE runs 100 m on copper; USB3 is a bench-and-short-run interface at a few metres. For the camera side of that fallback, board-level cameras filter by mount, interface and shutter, the camera finder does the same across the whole camera range, and the camera step of the configurator drops one into a full system. The board-level camera selection guide weighs the interfaces for embedded machines in detail.

Two parts that cover the fallback:

The LS-BCM-0003 is a 3.1 MP USB3 board-level camera: a 1/1.8" global-shutter sensor at 120 fps with a C-mount. The MV-CB016-10GM-M-W is a 1.6 MP GigE board camera with a 1/2.9" global-shutter sensor and an M12 lens mount. For the machine's cable run, cables includes drag-chain-rated GigE leads with screw locks:

What to send when you ask for help

Support escalations on these kits turn on data, not on description. Send nine things:

• A photo of the hardware exactly as wired, before you tidy it up.
• The exact first error string, copied as text.
• Both voltage readings from layer 1, with the meter's range.
• The lock-register value, and whether it changes when the lead flexes.
• The full bus sweep output showing every ACK.
• The exact board string from the boot log — one letter of difference in a board name can mean a different carrier, and every suggestion after a wrong board name is wasted time.
• The kit's documentation reference and revision.
• What you changed since the last working state, if there was one.
• Your deadline.

If layers one to three pass and layer four stalls, ask the vendor and the silicon vendor for a port to your exact board, with that package attached. That is the request that ends the loop.

Bring-up checklist

• Rail present at the deserializer input, inside the kit's printed input range.
• PoC voltage at the camera end matches the arithmetic above after the cable drop.
• Coax mated with power off, first bring-up lead a metre or two, no mid-span adapters.
• Lock bit set and stable for a full minute, including during a gentle flex of the lead.
• Deserializer and sensor each ACK at one 7-bit address, and the two differ.
• Alias programmed before the sensor driver loads.
• Camera node attached to your board's receiver endpoint, not the reference board's.
• Driver probe line in the boot log, sensor in the media topology, first frame captured.
• Ticket package complete: photo, error string, voltages, register values, sweep, exact board string.

Stuck on a layer after this pass? Send the checklist data through the contact page and we will work that layer with you. More integration debugging sits on the systems topic page.