31 I2C: Bring-Up and Diagnosis

31.1 Start With the Situation

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 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

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 Chapter Roadmap

Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.

31.5 Check I²C Arbitration

31.6 Quiz: I2C Protocol

Ground quiz questions with the visual at Figure 31.1. Start from I2C Interface Module, but keep LED visible while evaluating i2c provides a simple, efficient interface for connecting low-speed peripherals like sensors, eeproms, and displays. its two-wire design minimizes.

Trace the visual from I2C Interface Module to LED in Figure 31.1; verify PWR before concluding. Together those labels make i2c provides a simple, efficient interface for connecting low-speed peripherals like sensors, eeproms, and displays. its two-wire design minimizes testable. Apply their boundary when working through quiz questions.

31.7 Calculate Pull-Up Resistors

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): I2C spec limits sink current to 3 mA at VOL = 0.4 V. With 3.3 V supply: R_min = (VDD - VOL) / Isink = (3.3 - 0.4) / 0.003 = 967 Ω ≈ 1 kohm
2. Maximum resistor (rise time): The bus must rise from 0V to 70% of VCC within the rise time specification. 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-device bus at 400 kHz, use pull-ups between 967 Ω and 6.68 kohm. The standard 4.7 kohm falls comfortably in the middle — which is why 4.7 kohm is the universal default recommendation.

When 4.7 kohm does NOT work:

Debugging tip: If I2C works intermittently or only at 100 kHz but fails at 400 kHz, the pull-up resistor value is almost always the cause. An oscilloscope on SDA/SCL will show rounded rising edges (too slow) or ringing (too fast), confirming the diagnosis.

31.8 Label the Diagram

31.9 Code Challenge

31.10 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. 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.

The visual evidence for i2c shared-bus reliability record sits in Figure 31.2. Find I2C Protocol: Reading Temperature from BMP280 beside Master before interpreting i2c reliability is built from linked layers: shared open-drain wiring, an address byte with a read/write bit, ack slots after each byte, and.

Use Master to test I2C Protocol: Reading Temperature from BMP280 in the diagram at Figure 31.2. Then inspect Slave 0x76 as the final qualifier on i2c reliability is built from linked layers: shared open-drain wiring, an address byte with a read/write bit, ack slots after each byte, and. That sequence keeps i2c shared-bus reliability record tied to what is visibly labelled. 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.11 I2C Bring-Up Record

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.12 Rise Time Sets the Real I2C Speed

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.13 Knowledge Check

31.14 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.15 What’s Next

31.16 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.