I2C works great on a breadboard demo and then starts failing once real cable lengths and motor noise show up. I now treat I2C reliability as a physical-layer problem first and a software problem second.

My baseline checklist is simple: short wires, a shared ground reference, and one clear pull-up strategy. Mixed breakout boards often stack pull-ups in parallel, which can make rise times too fast and stress devices. I remove extra pull-ups and measure SDA and SCL with a logic analyzer before changing code.

On the firmware side, I always add retry logic around each sensor read and detect repeated NACK patterns. If retries exceed a threshold, I reinitialize the bus and record the event to serial logs. That gives me field data instead of guessing.

The biggest improvement came from separating high-current loads from sensor routing. Moving motor wires away from the I2C harness and adding a local decoupling capacitor near the sensor cluster reduced random timeouts almost completely.

Pull-up values that actually work

Pull-ups are the first thing I get right, because they set the rise time on both lines. My starting points for 3.3 V or 5 V buses:

  • 100 kHz (standard mode): 4.7 kΩ is a safe default for a short bus with a couple of devices.
  • 400 kHz (fast mode): 2.2 kΩ–3.3 kΩ, because the shorter bit period needs a faster rise time.
  • Long or heavily loaded buses: if rise times still look sluggish on the scope, drop toward the lower end, but don't go so low that the open-drain drivers can't pull the line down to a valid logic low.

The trap with breakout boards is stacked pull-ups: three boards each carrying their own 4.7 kΩ put roughly 1.6 kΩ in parallel across the bus, which is often too aggressive and can push devices out of spec. I keep one pull-up pair for the whole bus and remove the rest.

Bus and cable length

I2C was designed for on-board, short-distance communication. The practical constraint is total bus capacitance (the spec caps standard/fast mode around 400 pF), not a fixed length. In practice I keep unshielded jumper runs under ~30 cm at 400 kHz, and if I need more than about a meter I either drop to 100 kHz, use twisted pair with a solid shared ground, or add a proper I2C bus extender/buffer. Long ribbon cables next to motor wiring are where "works on the bench" quietly dies.

Standard vs fast mode tradeoff

Faster is not automatically better. 400 kHz cuts transaction time, which matters if you poll many sensors in a tight loop, but it demands tighter pull-ups, shorter wiring, and cleaner grounds. For a field node reading a few sensors once a second, 100 kHz is more forgiving and I lose nothing that matters. I only move to 400 kHz when the timing budget genuinely requires it, and I re-check rise times on the scope after switching.

NACK detect, retry, and bus recovery

On the firmware side I wrap each read in retry logic, and if the bus looks stuck (SDA held low by a confused slave), I clock it out manually before reinitializing Wire. The classic recovery is to toggle SCL up to nine times to let the slave finish its byte and release SDA, then issue a STOP.

#include <Wire.h>

const uint8_t I2C_SDA = SDA;   // A4 on classic Uno/Nano
const uint8_t I2C_SCL = SCL;   // A5 on classic Uno/Nano

// Manually clock SCL to free a slave that is holding SDA low.
void i2cBusRecover() {
  Wire.end();
  pinMode(I2C_SDA, INPUT_PULLUP);
  pinMode(I2C_SCL, OUTPUT);

  // Up to 9 pulses lets the slave finish its current byte and release SDA.
  for (uint8_t i = 0; i < 9 && digitalRead(I2C_SDA) == LOW; i++) {
    digitalWrite(I2C_SCL, LOW);
    delayMicroseconds(5);
    digitalWrite(I2C_SCL, HIGH);
    delayMicroseconds(5);
  }

  // Generate a STOP condition: SDA low->high while SCL is high.
  pinMode(I2C_SDA, OUTPUT);
  digitalWrite(I2C_SDA, LOW);
  delayMicroseconds(5);
  digitalWrite(I2C_SCL, HIGH);
  delayMicroseconds(5);
  digitalWrite(I2C_SDA, HIGH);
  delayMicroseconds(5);

  Wire.begin();
  Wire.setClock(100000);  // back off to standard mode on recovery
}

// Returns true on success. endTransmission() != 0 means NACK or bus error.
bool readRegister(uint8_t addr, uint8_t reg, uint8_t *out) {
  const uint8_t maxRetries = 3;

  for (uint8_t attempt = 0; attempt < maxRetries; attempt++) {
    Wire.beginTransmission(addr);
    Wire.write(reg);
    uint8_t err = Wire.endTransmission(false);  // repeated start
    if (err == 0 && Wire.requestFrom(addr, (uint8_t)1) == 1) {
      *out = Wire.read();
      return true;
    }

    // err: 2 = address NACK, 3 = data NACK, others = timeout/bus error.
    Serial.print(F("I2C read failed addr=0x"));
    Serial.print(addr, HEX);
    Serial.print(F(" err="));
    Serial.println(err);

    i2cBusRecover();
    delay(2);
  }
  return false;
}

The important part is not the retry count, it is that every failure gets logged with the address and error code. After a week in the field that log tells me whether I have a flaky device, a wiring problem, or noise correlated with a specific load switching on.

Sources

  • Imported from the previous version of the site (gaborl.hu). Original publication around 2025-02-18.
  • NXP Semiconductors, UM10204 — I2C-bus specification and user manual — pull-up sizing, rise-time limits, and the 3 mA sink-current constraint.