ELECTRONICS + EMBEDDED / BUS SYSTEMS / FIELD GUIDE 005

I²C IS SIMPLE UNTIL THE WIRES ARE REAL.

Two wires, open-drain signaling, addresses, acknowledgements. Beautiful. Then capacitance, pull-ups, partial power, level shifters, cable length, hot-plugging, clock stretching, and one target holding SDA low turn the elegant diagram into an archaeological site.

CORE IDEAI²C is electrically cooperative. It works because every participant releases the bus correctly and the passive pull-up network restores logic-high fast enough for the timing budget.

THE BUS

Open-drain signaling changes how you debug the problem.

I²C uses two lines: SDA for data and SCL for clock. Devices normally drive those lines low or release them; external pull-up resistors restore the high state. That arrangement allows multiple devices to share the bus without ordinary push-pull output contention and enables arbitration when more than one controller is present.

The consequence is that a logic-high is not actively driven in the usual sense. It is an RC charging process. The effective bus capacitance and pull-up resistance therefore become part of the digital timing. The schematic may draw SDA and SCL as perfect square waves. The oscilloscope gets the final vote.

PULL-UPS

A pull-up resistor is part of the timing network.

If the pull-up is too weak, rise time becomes long. If it is too strong, devices must sink more current while asserting low and may exceed their specified low-level output behavior. The useful value is therefore bounded on both sides.

The first-order intuition is simple: larger resistance or larger capacitance increases the time required for the released line to rise. Harnesses, connectors, level shifters, probes, PCB traces, and every attached device contribute capacitance. A bus that is clean with two devices on a small board can become marginal after somebody adds a meter of cable and four more targets.

NXP's I²C specification defines electrical and timing limits, including rise-time requirements by operating mode. Those limits are not decorative. They are the difference between a waveform that crosses the receiver threshold in time and one that arrives after the next part of the transaction has already begun.

SCOPE IT

Digital analyzers can hide analog failure.

A logic analyzer is excellent for decoding addresses, acknowledgements, repeated starts, arbitration, and transaction order. It is less useful for telling you why a line crossed its input threshold late, rang badly, or never reached a clean high level.

For intermittent bus problems, inspect SDA and SCL with an oscilloscope as electrical signals. Look at rise time, low level, overshoot, ringing, threshold crossing, clock stretching, and what happens when the suspect peripheral powers up or resets. If the decoded transaction says “NACK,” that describes the protocol observation. The scope may reveal the electrical reason.

STUCK BUS

One participant can hold everybody hostage.

A common failure state is a line that remains low when the controller expects the bus to be idle. This can happen when a target resets in the middle of a byte, loses power while its pins remain connected, wedges internally, or believes it is still in a transaction the controller has forgotten.

Simply reinitializing the controller peripheral may not clear the condition because the electrical bus state lives outside that peripheral. A useful recovery procedure begins by checking whether SDA and SCL are actually high. If SCL can be controlled and SDA is stuck low, some designs attempt a bounded sequence of clock pulses so a target waiting to finish a byte can advance and release SDA, followed by a STOP-like recovery condition. That behavior must be designed against the actual target devices and system safety requirements rather than copied blindly from a forum post.

If SCL itself is stuck low, clock stretching or a failed/partially powered device may be involved. At that point the important evidence is which device owns the low state and why.

CLOCK STRETCHING

The clock line can be a negotiation, not a metronome.

I²C allows targets in supported configurations to hold SCL low when they need more time. Controllers therefore need to distinguish legitimate stretching from a bus fault and impose a sensible upper bound so one failed target cannot stall the system forever.

A controller implementation that assumes SCL always follows the requested schedule can fail against perfectly compliant targets. The inverse problem also exists: firmware can tolerate effectively infinite stretch and turn one broken sensor into a system-wide deadlock.

Log stretch duration. Set a timeout based on the slowest legitimate device behavior plus margin. Escalate repeated timeouts into recovery rather than replaying the same transaction forever.

PARTIAL POWER

An unpowered device can still electrically participate.

Mixed power domains are a classic source of ugly behavior. If one device loses VCC while SDA or SCL remain pulled high from another powered domain, current may flow through protection structures or level-shifting paths. Depending on the device, that can back-power circuitry, clamp the line, violate absolute maximum conditions, or create half-alive logic whose behavior is wonderfully undocumented because it is outside the intended operating state.

Power sequencing therefore belongs in bus design. Ask what every device's pins do when its supply is absent, rising, falling, or below its valid operating threshold. If one branch can be switched off independently, isolation or carefully chosen level translation may be required.

LEVEL SHIFTERS

Bidirectional level translation is not invisible wire.

I²C's open-drain behavior makes certain passive FET level shifters attractive, but the translator adds capacitance, threshold behavior, leakage, and topology constraints. Active translators may add direction-detection rules, rise-time accelerators, one-shot circuits, or minimum pulse requirements.

When a bus fails only across the voltage boundary, measure both sides simultaneously. Do not assume a perfect copy of the waveform. Confirm that each side reaches valid high and low levels within timing limits under real capacitance and temperature.

ADDRESSING

Electrical health does not rescue an address collision.

Two targets configured for the same address can both acknowledge and may both respond, depending on the transaction. If their returned bits differ, the wired-AND nature of the bus can produce data that is neither device's intended response while still looking electrically legal.

Inventory addresses at boot when practical. Record strap-pin configuration. Treat modules with fixed addresses as integration constraints. If multiplexers are used to isolate duplicate addresses, their reset state becomes part of system startup architecture.

FIRMWARE

Do not flatten every failure into “I²C error.”

Preserve enough status to distinguish address NACK, data NACK, arbitration loss, stretch timeout, peripheral timeout, bus busy on entry, stuck SDA, stuck SCL, and controller reset. Those states point toward different mechanisms.

Retry policy also matters. A single retry may survive a transient. Unlimited retries can conceal a permanently failed sensor while monopolizing the bus. Recovery should be bounded, observable, and tied to the importance of the device.

FIELD METHOD

A practical failure sequence.

1. Inspect idle levels. Confirm SDA and SCL are actually high before trusting software status.

2. Measure rise time and low level. Compare the real waveform against the mode and device limits.

3. Reduce the topology. Remove branches or targets until the fault disappears, then rebuild deliberately.

4. Correlate with power state. Watch every relevant rail while the bus fails.

5. Inspect both sides of translators. A valid waveform on one side proves very little about the other.

6. Preserve controller error reason. NACK, arbitration loss, stuck-busy, and timeout are not synonyms.

7. Test recovery under forced interruption. Reset targets mid-transaction, interrupt power, and verify that the bus returns to a known state without requiring a human to touch it.

BOTTOM LINE

I²C failures are usually analog, stateful, or both.

The protocol is simple enough that developers often debug it entirely in software. That works until the failure lives in the rise time, power boundary, pull-up network, translator, or a peripheral that remembers more of the last transaction than the controller does.

The bus is two wires. The system around those wires is not.