31 I2C: Bring-Up and Diagnosis

31.1 Start With the Situation

This section: Start With the Situation — The bus rules are known, but a real sensor still may not answer.

The bus rules are known, but a real sensor still may not answer. The team must run a repeatable bring-up, inspect timing and pull-ups, and separate address, wiring, arbitration, and device faults.

31.2 Overview

This section: Overview — This route turns I2C theory into sensor bring-up and fault diagnosis evidence.

This route turns I2C theory into sensor bring-up and fault diagnosis evidence.

This is part 2 of 2. Review I2C: Transactions and Bus Design when you need the first route.

31.3 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

• bring up a BME280 on an I2C bus
• diagnose pull-up and clock-stretching failures
• verify arbitration and transaction evidence

31.4 Check I²C Arbitration

This section: Check I²C Arbitration

31.5 Quiz: I2C Protocol

This section: Quiz: I2C Protocol — Read Figure 31.1 to check the three levels these questions draw on: the wiring, the address byte, and what happens when the bus is shared.

Read Figure 31.1 to check the three levels these questions draw on: the wiring, the address byte, and what happens when the bus is shared.

+

The physical band shows one SDA and SCL pair reaching an Arduino controller and two devices, a sensor at 0x76 and a display at 0x3C. Only the device whose address matches answers, and the other ignores the transaction. The data band works that address into a byte. The 7-bit address is doubled and the read/write bit is added, so 0x76 becomes 0xEC to write and 0xED to read, with an acknowledge after each byte. The shared-bus band at the foot of Figure 31.1 covers the rest. A device can hold the clock low to buy time, and a controller that loses arbitration backs off.

31.6 Calculate Pull-Up Resistors

This section: Calculate Pull-Up Resistors — Choosing the right pull-up resistor value is the single most common source of I2C failures.

Choosing the right pull-up resistor value is the single most common source of I2C failures. Too high and the bus cannot rise fast enough; too low and the devices cannot sink enough current to pull the bus low.

The constraints:

1. Minimum resistor (max current): For this Standard/Fast-mode example, use a device rated to sink 3 mA while keeping VOL at or below 0.4 V. With 3.3 V supply: R_min = (VDD - VOL) / Isink = (3.3 - 0.4) / 0.003 = 967 Ω ≈ 1 kohm. Check the actual devices’ limits.
2. Maximum resistor (rise time): The specified rise-time interval is from 30% to 70% of VCC. Rise time depends on bus capacitance.

Rise time formula:

$t_r = 0.8473 \times R_{pull} \times C_{bus}$

Where the maximum rise time is 1000 ns for standard mode (100 kHz) and 300 ns for fast mode (400 kHz).

Calculating bus capacitance:

Maximum resistor for 400 kHz (fast mode):

Result: For this 3.3 V, 53 pF bus at 400 kHz, the calculated pull-up window is 967 Ω to 6.68 kohm. The common 4.7 kohm default falls inside this window, which is why it works for most short buses; recheck if capacitance grows.

When 4.7 kohm does NOT work:

Debugging tip: If I2C works at 100 kHz but fails at 400 kHz, the pull-up/capacitance rise time is the most common cause; also check clock stretching and device speed support. A scope shows rounded edges (too slow) or ringing.

31.7 Label the Diagram

This section: Label the Diagram

31.8 Code Challenge

This section: Code Challenge

31.9 I2C Shared-Bus Reliability Record

This section: I2C Shared-Bus Reliability Record — I2C works because every device shares the same two wires and follows the same electrical rule: devices may pull SDA or SCL low, but pull-up resistors bring the lines high again.

I2C works because every device shares the same two wires and follows the same electrical rule: devices may pull SDA or SCL low, but pull-up resistors bring the lines high again. That makes the bus simple, but it also means one wrong device, weak pull-up, duplicate address, voltage mismatch, or stuck line can affect every device on the bus. The firmware call that says read register 0xF7 from address 0x76 only succeeds when the physical bus, address phase, ACK bits, timing, and recovery assumptions all hold together.

Good I2C design is therefore not just picking a library. It is a bus health record: addresses are unique, pull-ups fit the capacitance and speed, voltage levels match, transactions ACK, and firmware can recover when a slave leaves SDA low. That record matters most in IoT nodes where several low-speed parts share the bus: a BME280 sensor, an EEPROM, a real-time clock, and an OLED display may all look independent in software, but electrically they are attached to the same SDA/SCL pair.

The overview decision is whether the bus boundary is appropriate for the job. I2C is a strong fit for short, local, board-level communication where the controller owns the transaction schedule and peripherals are close enough that capacitance stays controlled. It becomes fragile when a design treats it like an installation cable, mixes voltage domains casually, hides duplicate fixed addresses behind library defaults, or adds modules until the pull-ups can no longer produce clean edges at the chosen speed.

Figure 31.2 answers a narrow question: what does one successful sensor read look like on the wire?

+

Read the exchange in Figure 31.2 from the top down. The controller opens the bus, then names the device it wants and says it intends to write. The device answers, and that answer is the whole point: an addressed part confirms every byte it accepts, so a missing confirmation is the first hard evidence of a wiring, address or voltage fault. The controller writes the register it wants, restarts without releasing the bus, and names the same device again, this time to read. One data byte comes back. The controller then declines the next byte and closes the bus, which is how the device learns the transaction ended. The panel beneath collects the electrical conditions that every one of those steps assumes.

Two shared wires: SDA carries address and data. SCL provides timing. Every attached device sees both lines, so wiring length, module count, connector quality, and breadboard capacitance accumulate into one bus limit.

Open-drain signalling: Devices only pull low. Pull-ups create high levels, set rise time, and determine whether standard mode, fast mode, or Fast-mode Plus is realistic for the assembled hardware.

Addressed turns: Only the addressed device should ACK and respond. Duplicate fixed addresses make two devices answer at once; reserved addresses and shifted address bytes create equally confusing scanner results.

31.10 I2C Bring-Up Record

This section: I2C Bring-Up Record — A reliable I2C build has a short verification record before firmware assumptions harden.

A reliable I2C build has a short verification record before firmware assumptions harden. The record proves the physical wiring, electrical timing, address map, and recovery behavior under the target clock speed. Start it before sensor-driver integration: record the board voltage, the microcontroller pins assigned to SDA and SCL, the pull-up source, the expected device addresses, and the clock rate that the final product will use.

The practitioner mistake is to treat an I2C scanner result as complete proof. A scan only proves that some device pulled ACK during the address phase. It does not prove the register map is correct, that read/write bytes are formed correctly, that clock stretching is handled, that the bus survives reset timing, or that the same wiring will work at 400 kHz after all devices and cables are installed.

Before coding: Confirm voltage compatibility, shared ground, pull-ups, address pins, and cable length. These are hardware facts, not software preferences, and they should be visible in the schematic or bring-up log before the first driver abstraction is trusted.

During bring-up: Run a scanner, then capture at least one successful register read and one expected failure path such as no device at an unused address. Use the device datasheet register, not only a high-level sensor library example.

Before release: Test at the final clock speed with all devices attached, then verify timeout and bus-recovery code instead of assuming the library handles lockup. Repeat after warm reset and power interruption because stuck-SDA faults often appear during startup sequencing.

31.11 Rise Time Sets the Real I2C Speed

This section: Rise Time Sets the Real I2C Speed — I2C looks digital in code, but the rising edge is analog.

I2C looks digital in code, but the rising edge is analog. The line rises through a resistor into the total bus capacitance, so more devices, longer traces, jumpers, and breadboards all slow the transition from low to high. The receiver samples logic levels at clocked moments; if the edge is still rising, the bus can fail only at higher speed or only with every device attached. This is why the NXP I2C-bus timing limits specify rise-time budgets, not just clock rates.

The useful mental model is an RC charge curve. With a larger pull-up resistor, the device sinks less current when it pulls low, but the high transition is slower. With a smaller pull-up, the edge is faster, but every device must be able to pull the line below the valid-low threshold while sinking the extra current. A design that moves from 4.7 kohm to 2.2 kohm may fix a 400 kHz rise-time failure, but it also changes power and VOL margin.

Addressing and timing failures often look similar from firmware: a missing ACK. The debug path is to separate causes. If an address scan finds nothing, check power, ground, pull-ups, voltage, and address shifting. If a device appears at 100 kHz but fails at 400 kHz, inspect rise time and capacitance. If the bus hangs after resets, implement recovery pulses and timeouts before retrying the transaction.

The same physical rule explains multi-master arbitration. Each controller watches SDA while transmitting; if it releases the line high but another controller pulls it low, it has lost arbitration and must stop driving. That wired-AND behavior prevents direct output contention, but it does not make multi-master systems automatically simple. The software still needs ownership rules, bounded retries, and logging that distinguishes arbitration loss from a missing slave ACK.

Rise-time limit: The pull-up resistor and bus capacitance define whether the line reaches a valid high level before the next clock sample. Fast mode leaves far less time for the same edge than standard mode.

Clock stretching: A slave may hold SCL low while it prepares data. Firmware must tolerate this within a bounded timeout, and the timeout should be measured against the slowest real device on the bus.

Bus lockup: A reset or interrupted transaction can leave SDA low. The master needs an explicit recovery sequence, commonly clocking SCL until the slave releases SDA, then issuing STOP and reinitializing the peripheral.

31.12 Knowledge Check

This section: Knowledge Check

31.13 Summary

This section: Summary

This chapter covered I2C (Inter-Integrated Circuit) protocol:

• Two-wire bus (SDA for data, SCL for clock) supports multiple devices
• Open-drain outputs with pull-up resistors (typically 4.7k) enable multi-master operation
• Pull-up value depends on bus capacitance — 4.7k works for most setups, use 2.2k for long cables or many devices
• 7-bit addressing allows up to 112 devices on a single bus
• Synchronous protocol with master-controlled clock and optional clock stretching
• Half-duplex communication with START, STOP, and ACK/NACK conditions
• Common devices: Temperature sensors (BME280), displays (SSD1306), IMUs (MPU6050), RTCs (DS3231)

31.14 What’s Next

This section: What’s Next

31.15 Key Takeaway

This section: Key Takeaway — I2C is useful for short, shared-board communication, but pull-ups, bus capacitance, addressing, clock speed, and stuck-bus recovery limit how far it can stretch.

I2C is useful for short, shared-board communication, but pull-ups, bus capacitance, addressing, clock speed, and stuck-bus recovery limit how far it can stretch.