Voice coil motor autofocus driver init fails: diagnose the I2C fault

The symptom looks impossible: the module streams a sharp, steady image, frames never drop, and yet autofocus never moves and manual focus does nothing. That combination is the signature of a voice coil motor (VCM) driver whose init never completed — the actuator IC on the module never acknowledged its I2C address, so the kernel never registered a lens controller.

The diagnosis below runs in the order that costs the least time: read dmesg for the actuator driver rather than the sensor, confirm the driver actually bound, scan the bus for the actuator's address, reseat the flex, then decide between a stack fix and a module replacement. The examples use an imx519 sensor module paired with its ak7375 actuator driver on an embedded Linux board; the same sequence applies to any module whose focus actuator rides on its own I2C driver.

Why does the camera stream fine but autofocus never moves?

The sensor and the focus actuator are two separate chips with two separate I2C addresses and two separate kernel drivers, so a module can stream a perfect image all day while its voice coil motor never receives a single move command.

On this class of module the sensor driver (imx519 here) owns the imaging chip: it configures registers over I2C and pushes frames out the MIPI CSI-2 lanes. The focus actuator is a second I2C client — ak7375 on these modules — that turns position commands into coil current and holds the lens carrier against its return spring. The drive electronics are plain current control; the same principle is worked through in this H-bridge drive design for a voice coil actuator.

The camera framework (libcamera on embedded Linux boards) runs its autofocus algorithm against a registered lens controller. When the actuator driver never probed, there is no controller, so the AF sweep and every manual focus write are dropped without an error on screen. You see a correctly exposed image frozen at whatever distance the lens last rested at. The counterpart failure, a sensor that is detected but streams nothing, is covered in MIPI sensor detected but streaming fails: power, clocks, device tree.

Two events usually put you here. The module was physically disturbed: a flex lifted, a socket contact walked, the barrel took a knock. Or the software changed: an update replaced one of the two drivers but not the other. It worked yesterday points at the first cause; it stopped after the update points at the second.

What does dmesg actually tell you about the actuator driver?

Search dmesg for the actuator module name — in the imx519-plus-ak7375 pairing that is ak7375 — because a name inside a "Modules linked in" block proves only that the driver file loaded, while the probe line decides whether the actuator answered.

Reboot first so the log holds one clean boot, then read three possible outcomes:

• A probe line naming the driver, its I2C adapter and the address, ending in success: the actuator bound. Move on to the pipeline checks in the next section.
• A probe line ending in a negative errno: the driver ran and was refused. -121 (EREMOTEIO) means nothing acknowledged the actuator's address, so it was absent, unpowered or declared at the wrong address.
• No actuator lines at all: the driver never loaded. The overlay does not declare the actuator node, or the driver is not installed. The repair path is in camera loads the wrong sensor driver: read dmesg, fix the overlay and camera driver device tree mismatch: diagnose missing DTBs.

One trap: a grep that returns only a "Modules linked in" block has told you nothing about probe status. That string is the module inventory a kernel dump prints, and it lists every loaded driver whether or not it bound. Judge binding by probe messages, never by presence in that list.

Under the hood, a focus actuator registers as a V4L2 sub-device: the driver binds to the chip at probe time, then attaches to the media pipeline as a lens-type entity alongside the sensor. That registration is what autofocus looks for when it asks for a lens to move — if the sub-device never registered, the framework has no lens to hand the algorithm.

How do you confirm the actuator driver bound and registered?

A bound actuator shows up as a registered lens controller that the camera framework can drive; if only the sensor driver bound, the application finds no focus control and silently drops every autofocus and manual-focus request.

Binding has two halves. The I2C probe binds the driver to the chip; the camera framework then has to accept that lens controller for this sensor. A clean probe with no focus control in the application usually means the two halves come from different builds: kernel modules from one release, userspace stack from another. Update both from one release set, reboot, and retest before you touch hardware.

Rank the causes by how often each survives a first look:

Work the table top to bottom; the first two rows explain most "camera streams, focus dead" reports.

How do you test the actuator's I2C address on the bus?

Scan the module's I2C bus with i2cdetect and compare two addresses: the sensor's, which must ACK because you are streaming, and the actuator's, which must also ACK — when only the actuator's address is silent, the link or its supply, not your software, is the problem.

Take both addresses from the module's device tree overlay: the sensor node and the actuator node each carry a bus number and a 7-bit address. Then scan that bus: i2cdetect -y 1, where 1 stands in for whichever bus your overlay puts the module on. A printed address means a device acknowledged, UU means a bound driver already holds the address, and -- means nothing answered.

Read the two results against each other. Sensor acknowledged or UU while the actuator shows --: the actuator is absent, unpowered or dead, a hardware path. Both UU: both drivers bound, so the fault sits in the pipeline, not the bus. The sensor's ACK doubles as proof that the shared SDA and SCL wiring works end to end, which sharpens everything that follows. For the deeper failure modes of this scan, see camera I2C communication failure: diagnose sensor probe errors and I2C error -121 on a camera sensor probe: fix the physical link.

One software cause mimics a dead actuator: an address collision. When two devices on the bus answer the same address, the driver that probes second loses, and on many modules that is the actuator. The bus options are worked through in two image sensors with the same I2C address: bus options that work.

Can the ribbon cable kill focus but not the image?

If the sensor ACKs and streams, the I2C clock and data lines physically reach the module, so a flex fault that kills focus must sit in a contact used only by the actuator — its supply or enable line — which is why a one-minute reseat revives some dead actuators.

The flex carries MIPI data lanes, the shared I2C pair and several supply rails. The stream proves the MIPI lanes and the sensor's supply; the sensor's ACK proves SDA and SCL at the sensor's address. A focus-killing cable fault can still break one contact reserved for the actuator, which is why reseating belongs early in the sequence rather than at the end.

Power down, reseat the flex at both ends, and look for a crease or a whitened fold line before reapplying power. Rescan the bus. If the address is still silent, wiggle the flex gently during the scan: an address that flickers in is an intermittent contact, not a dead IC. A module that failed after being handled usually fails exactly here.

How much does a dead autofocus actually matter at your working distance?

At a 100 mm working distance with a 4 mm module lens at f/2.8 and 1.6 μm pixels, total depth of field is about 11 mm, so a dead autofocus stays invisible until the part or the bracket moves more than about 5 mm from the set distance.

Worked example: a 4 mm module lens at f/2.8, so N = 2.8, focused at WD = 100 mm, on a sensor with 1.6 μm pixels, taking the blur budget as 2 pixels: c = 2 × 1.6 μm = 3.2 μm = 0.0032 mm. Magnification m = 4/(100 - 4) = 0.0417. Total depth of field = 2 × 2.8 × 0.0032 mm × 1.0417 / 0.00174 ≈ 10.7 mm, about ±5.3 mm around the set distance. A 1/1.8" sensor is about 7.2 mm wide, so the field at that distance is 7.2 / 0.0417 ≈ 173 mm across.

Depth of field scales linearly with f-number and with the blur budget, and inversely with magnification squared. Stop the same lens to f/4 and the total grows to about 15.3 mm (±7.7 mm). Halve the working distance to 50 mm, m becomes 0.0870, and the total collapses to about 2.6 mm: close work is where a dead actuator hurts first.

Decision: add up your worst-case distance variation — part height tolerance, fixture repeatability, thermal drift. Under about 5 mm here, a fixed-focus setup tolerates the dead actuator. Over it, fix the actuator, move the camera back, stop down with more light, or bin 2 × 2 to double the effective pixel size and roughly double the depth of field.

When should you replace the module instead of debugging?

Replace the module once the actuator's address stays silent on a second known-good board with a freshly seated flex: actuator ICs are sealed inside the lens barrel and are not field-serviceable, and a module that fails that cross-test will fail on your production boards too.

Run the cross-test in this order:

1. Reseat the flex at both ends on a second, known-good board and boot it with the same overlay.
2. Scan the bus there. The actuator's address ACKs or shows UU: the first board's overlay, supply or socket is the fault, so go back to the binding and bus sections.
3. The address stays silent with a fresh flex on a known-good board: the actuator IC is dead. Replace the module; the IC, coil and lens carrier are bonded inside the barrel.

If the working distance never changes — one bracket, one chute, one part height — a fixed-focus board camera is the sturdier replacement, because it removes the only moving part in the module. These three cover the case over GigE:

The LS-BCM-0056 keeps 12 MP on a C-mount, so focus is set on the barrel; the LS-BCM-0020 trades down to 6.3 MP on CS-mount; the MV-CB016-10GM-M-W covers 1.6 MP in an M12 barrel for tight builds. If the parts move, hold image timing with a global-shutter module:

The LS-BCM-0003 pairs a 1/1.8" global shutter with 120 fps over USB3, so a focus set once on the C-mount barrel holds frame after frame. The software side of a swap — driver, overlay and end-of-life planning — is laid out in board level camera replacement when a sensor goes end of line, and the board-level cameras category is where to shortlist mounts and interfaces.

How do you keep autofocus alive on the next build?

Gate every build on a focus sweep that actually moves the lens — command nearest, then farthest, and assert the image blurs and sharpens — because a bring-up test that only checks for frames catches exactly this failure and waves it through to production.

• Gate bring-up on the sweep: a healthy VCM completes near-to-far travel in a few tens of milliseconds, typical for lens actuators, so the whole check adds under a second.
• Pin the kernel modules and the camera stack to one release set and update them together; a mixed set loses focus control without ever losing a frame.
• For stations with a fixed working distance, fit a fixed-focus lens and lock it; calibrate a camera with autofocus: lock the focus first keeps calibration and focus drift from fighting each other.
• Decide fixed focus versus actuator at design time; the board camera evaluation checklist for inspection systems walks the questions that decide it.
• On factory GigE hardware, subscribe to events instead of watching frames; get a GenICam notification when one-push autofocus has finished shows the pattern.

To shortlist a replacement with focus you set by hand, start at the camera finder or step through the camera configurator. For factory stations, area scan cameras covers C-mount cameras where focus lives on the lens barrel, not on an I2C actuator.