I2C slave NACK on address read: fix the silent peripheral

You poll a board you built into your machine for six bytes. The first read after power-up returns them. Every read after that fails with a NACK on the address byte, and only a reset brings the data back once. That pattern rules out wiring, pull-ups and a wrong address, because all three would fail on the very first transaction. It points at a peripheral that stops claiming its address once it has served one request — a firmware and bus-timing problem with a short list of causes. This guide gives you the three tests that separate them, the pull-up arithmetic that keeps the edges fast enough, and the fix that matches each symptom, including the variant where the silent peripheral is a camera module.

What a NACK on the address byte means

An I2C transaction opens with the controller clocking seven address bits and a read/write bit onto the bus. On the ninth clock the controller releases SDA, and the addressed peripheral must pull it low within that bit time. Pulled low is an ACK; left high is a NACK, and it means nothing on the bus claimed the address at that instant.

Your first transaction ACKs. That single fact clears the wiring, the pull-up values and the address, at least while the peripheral is fresh. The fault is not the bus and not the number: it is the peripheral's willingness to answer twice. Something in its port logic disarms after one transaction, or it cannot get its answer ready inside the timing the controller allows.

Likely causes, most probable first

1. The request handler is not re-armed. Many two-wire ports treat an address match as a one-shot event: hardware serves the first transaction, then waits for software to re-enable the match before it will ACK again. A reset re-enables it, which is exactly the once-per-boot behaviour you are seeing.
2. Clock stretching one side cannot honour. A peripheral that builds its answer in software may hold SCL low while it loads the first byte. If the controller's port samples the acknowledge without waiting for stretched clocks, it reads a bit that never arrived and logs a NACK.
3. The address is written in 8-bit form. This only fits when the first read fails too. A data sheet value of 0x04 carries the read/write bit already; the 7-bit address a scanner or library expects is 0x02.
4. Edges too slow for the cable. Pull-ups near 10 kΩ over more than a few tens of centimetres push the rise time past its limit, and a marginal ninth bit decodes as a NACK.
5. The peripheral never answers at all. Power, a held reset line or reassigned port pins put it off the bus entirely; a scan finds nothing.

Causes 1 and 2 fit a peripheral that ACKs once. Causes 3 to 5 fit one that never ACKs. Work them in that order.

Test 1: scan the bus and check the address format

Run a bus scan right after a fresh boot, then again after the first successful read. Sweep the valid 7-bit space, 0x03 to 0x77; addresses outside it are reserved by the specification and never belong to a peripheral.

Two outcomes settle the case. Finding the board once and then losing it confirms a disarmed peripheral, so go to Test 2. Never finding it moves the fault to addressing or power, so stay here.

Check the format next. Data sheets that print 8-bit addresses double the real value: 0x04 is 7-bit address 0x02 with the write bit set, 0x05 the same address for read. Call the board at 0x02 in your code and scanner. Any data sheet address of 0x78 or above is 8-bit and should be halved.

If the scan shows two boards on one address, change one of them; collisions look intermittent, not once-per-boot. The options in two image sensors with the same I2C address: bus options that work cover the ways out.

Test 2: watch the second transaction

Put a logic analyzer on SDA and SCL, decode I2C at the bus clock, and capture across the transition from the good first read to the failed second one. Three signatures separate the causes:

• SDA high on the ninth clock, SCL free. The peripheral never claimed the address: its match logic is disarmed. Fix in the firmware section below.
• SCL held low by the peripheral, then a NACK. The peripheral tried to stretch the clock and the controller refused to wait. Enable stretching on the controller port, or keep this bus at 100 kHz where a software-served peripheral can keep up.
• SDA or SCL stuck low and the bus hangs. A slave is wedging the bus mid-byte; the controller has to clock through it or the peripheral needs a power cycle.

Frame by frame, the first and second transactions should be identical up to the ninth bit. Whatever differs in that window is your cause. When the controller is a small single-board computer, check its port's stretching behaviour too; host-side I2C configuration for a peripheral board walks that set-up.

Test 3: slow the clock and size the pull-ups

Drop the bus to 100 kHz and retest. If the NACKs stop, the peripheral was missing its preparation window, and the honest fix is a slower bus or real clock-stretching support on the controller. If they persist at 100 kHz, timing is innocent and the firmware fix carries the case.

While you are at the bench, size the pull-ups for the capacitance you actually have, not a breadboard default. Two limits book the value: the peripheral must sink the pull-up current to a valid low, and the rise time must fit the bit period. The I2C-bus specification puts the sink point at 0.4 V with 3 mA and gives the rise-time ceiling as R_max = t_r(max) / (0.8473 × C_bus), with t_r(max) at 1000 ns for 100 kHz and 300 ns for 400 kHz.

Worked example, two boards 0.5 m apart on ribbon: cable adds about 50 pF/m, so 25 pF per line, and the port pins add roughly 30 pF, so budget C_bus ≈ 55 pF.

At 400 kHz the ceiling is R_max = 300 ns / (0.8473 × 55 pF) ≈ 6.4 kΩ. Pick 4.7 kΩ: rise time = 0.8473 × 4.7 kΩ × 55 pF ≈ 219 ns, inside the limit with margin. At 100 kHz the same resistor gives a 219 ns rise against a 1000 ns ceiling, five times inside it. A 4.7 kΩ pull-up serves a 400 kHz bus up to about 75 pF; past that, drop to 3.3 kΩ (good to about 107 pF) or fall back to 100 kHz. Never go below the 967 Ω sink floor.

Between boards, run the pair through shielded multicore cable with a direct ground conductor, shield tied at one end. The LS-CBL-0300 is an M8 8-pin power and I/O cable, male connector to open end with eight cores, in a 7 m length, built for drag-chain motion; the spare cores take a second ground or a peripheral reset line.

If the analyzer shows garbage rather than a clean NACK — glitches, short pulses, levels that never reach the rails — treat it as a wiring fault instead: I2C error -121 on a camera sensor probe: fix the physical link walks that path for a camera module.

Fix the peripheral: re-arm the answer path

The once-per-boot signature has one real fix: make the peripheral claim its address for every transaction, not only the first.

1. Re-register the request-event callback in the main loop, not only at start-up. On ports that drop the hook after one transaction this re-arms it; on ports that keep it, the call does no harm.
2. Clear the address-match status in the order the port demands. On some MCU families the match flag must be cleared before the data register is touched, or the port stalls after one byte. A write-up of an I2C peripheral address-match and RXNE fix shows that exact order-of-operations trap; your MCU's reference manual gives the equivalent order for its own port.
3. Fill the answer buffer outside the callback. Prepare the payload at loop level; the callback's whole job is pushing ready bytes. At 100 kHz a byte must leave within 90 µs of the acknowledge, at 400 kHz within 22.5 µs — no formatting or computation fits that window.
4. Keep the loop free of blocking calls. A loop parked in a long delay starves polled implementations of the callback and hides the re-arm; if your library serves requests from an interrupt, a non-blocking loop still costs nothing.

After the change, the analyzer should show an ACK on the ninth bit of every transaction, and the host should receive the six bytes on every poll, not just the first.

When the peripheral is a camera module

Camera modules are I2C peripherals in their own right: a host reads sensor identification and configuration registers over I2C at boot, and re-reads them whenever it re-initialises the port. A module that answers its first probe and then goes quiet fails for the same reasons a custom board does, so the tests above apply unchanged. When the failure sits at the sensor probe on the module's internal bus, camera I2C communication failure: diagnose sensor probe errors and MIPI camera sensor ID mismatch: diagnose the wrong I2C probe cover the module-specific paths, and multiple camera modules on one host: shared bus limits covers several modules sharing one pair.

If you are still choosing the module that hangs off your host, bare board-level cameras are the format built for this kind of integration. The MV-CB016-10GM-M-W is a 1.6 MP GigE board-level camera with a global shutter and an M12 lens mount; the LS-BCM-0020 is a 6.3 MP board-level camera with a rolling shutter, a CS-mount and a GigE interface.

Both are meant to be built into a machine rather than bolted to a bracket, and both sit in the board-level cameras line, filterable in the camera finder.

Prevention: keep the bus answering

• Size one set of pull-ups per bus with the formula above: 3.3 kΩ to 4.7 kΩ from the 3.3 V rail, fitted at one point, not duplicated on every board.
• Default to 100 kHz between two boards; move to 400 kHz only when the run is under about 0.5 m and the rise-time budget still closes.
• Scan at every boot and log the map. A map that changes between boots catches address conflicts and missing peripherals before they become field failures.
• Give the two boards a direct ground conductor and tie the cable shield at one end only.
• Arm a watchdog on the host: three consecutive NACKs trigger a peripheral re-init or a power cycle of the peripheral rail, which turns a silent failure into a logged one.
• The specification caps a bus at 400 pF, but your rise-time budget is almost always the tighter limit, so trust the numbers, not the length of wire.

The decision for each case

Run the three tests in order and the table hands you the fix; the once-per-boot case ends with a re-armed callback and an ACK on every poll. If the bus belongs to a vision build and you want the surrounding parts specified around it, start from the cables the bus runs on and the accessories finder, then let the vision configurator walk the rest of the chain step by step. More bus-level fault-finding lives on the systems topic page.