I2C is supposed to be simple. Two wires, a master, a few slaves, done. And most of the time it works — until it doesn't. Then you're staring at a logic analyzer wondering why your sensor stopped responding after 30 minutes, or why the bus works on the bench but fails in the enclosure.
After debugging enough I2C issues across dozens of boards, the same mistakes keep showing up. Here are seven of the most common ones, what they look like in practice, and how to fix them.
Mistake #1: Using the Wrong Pull-Up Resistor Value
This is the big one. The I2C bus needs pull-up resistors on both SDA and SCL — there's no getting around that. But the value you pick matters enormously.
What goes wrong: Engineers either copy a value from a reference design without checking (usually 4.7 kΩ or 10 kΩ) or they calculate it once for a simple two-device bus and never update it when more devices get added.
Why it matters: Too high a resistance, and your rise times get sluggish. The bus might work at 100 kHz but fall apart at 400 kHz. Too low, and you waste power and risk exceeding the IOL spec of your devices (typically 3 mA for standard mode, though some devices handle more).
How to get it right:
The pull-up value depends on three things:
- Bus capacitance (all devices + trace capacitance, typically 10–20 pF per device)
- Desired rise time (1 μs for standard mode, 300 ns for fast mode)
- Supply voltage
Rp(max) = tr / (0.8473 × Cb)
Where:
tr = target rise time
Cb = total bus capacitance
For a 400 kHz bus with 100 pF total capacitance at 3.3V:
Rp(max) = 300 ns / (0.8473 × 100 pF) = 3.54 kΩ
So a 3.3 kΩ resistor would work, but a 4.7 kΩ would be too slow. A 2.2 kΩ gives you comfortable margin.
Fix: Calculate your pull-ups based on your actual bus. Don't just copy from a dev board schematic.
Mistake #2: Ignoring Total Bus Capacitance
The I2C specification sets a hard limit of 400 pF for the total bus capacitance. That includes:
- Pin capacitance of every device on the bus (typically 5–10 pF each)
- Trace capacitance (about 1–2 pF per cm on a typical FR-4 board)
- Any connector or cable capacitance
- The pull-up resistors themselves (small contribution)
What goes wrong: You string together 8–10 devices on long traces, maybe through a connector or two, and suddenly you're at 350+ pF. The bus starts glitching, especially at higher speeds.
The fix is straightforward:
- Keep traces short (under 15 cm total bus length for fast mode)
- Minimize the number of devices on a single bus segment
- Use an I2C bus buffer or multiplexer for long or heavily loaded buses
- Account for cable capacitance if your bus goes off-board (a 1-meter Cat5 cable adds ~50–60 pF per pair)
Mistake #3: Mixing Voltage Levels Without a Level Shifter
You've got a 3.3V microcontroller talking to a 1.8V sensor. Easy, right? Just connect them? No. Absolutely not.
What goes wrong: The 3.3V master pulls the bus high to 3.3V. The 1.8V device sees 3.3V on its I/O pins, which can damage it — or at minimum, cause excessive current through its ESD protection diodes. Over time, this degrades the device.
Even if nothing burns up immediately, the 1.8V device's logic-high threshold might not be compatible with 3.3V signaling, leading to unreliable reads.
The fix: Use a bidirectional I2C level shifter. The classic circuit uses a MOSFET (BSS138 is the go-to) with pull-ups on both sides. Or use an integrated level shifter like the PCA9306 or TXB0108.
This isn't optional. It's not a "nice to have." If your bus voltages don't match, you need a level shifter. Full stop.
Mistake #4: Star Topology Routing
I2C is a bus — it's meant to be a linear daisy chain. SDA and SCL run from the master to each slave in sequence, with stubs as short as possible.
What goes wrong: You route SDA and SCL from the master out to each device in a star pattern, with long traces branching off in different directions. Each branch acts as a transmission line stub. At higher speeds, reflections from those stubs corrupt the signal.
The fix: Route the bus in a daisy chain. Run SDA and SCL past each device in sequence. If you need a star topology, use an I2C hub or switch (like the PCA9548A) to create separate bus segments.
Keep stub lengths under 5 cm for fast mode. For standard mode (100 kHz), you can get away with more, but it's still bad practice.
Mistake #5: No Attention to Pull-Up Placement
Even with the right resistor value, where you place the pull-ups matters.
What goes wrong: You put the pull-ups next to the master, but the bus runs 20 cm to reach a slave at the far end. The RC time constant at the slave end is worse because of the trace resistance and capacitance between the pull-up and the far device.
The fix: Place pull-ups roughly in the middle of the bus, or use split pull-ups — one at each end. This gives the most balanced rise times across all devices on the bus.
For short buses (under 10 cm), placement matters less. For anything longer, pay attention.
Mistake #6: Forgetting About Clock Stretching
Some I2C slaves use clock stretching — they hold SCL low after receiving a byte to signal the master to wait while they process data. This is perfectly legal per the I2C spec.
What goes wrong: Your master doesn't support clock stretching (or has it disabled). The slave holds SCL low, the master ignores it and keeps clocking, and the bus gets out of sync. Data gets corrupted.
Some common master peripherals — notably certain implementations on Raspberry Pi and some STM32 configurations — have known issues with clock stretching.
The fix:
- Check whether any of your slaves use clock stretching (many ADCs, EEPROMs, and sensors do)
- Verify your master handles it correctly
- If your master doesn't support it, avoid slaves that require it, or use a software I2C implementation that handles stretching properly
Mistake #7: No Bus Testing Under Real Conditions
Your I2C bus works perfectly on the bench at room temperature with a 10 cm test cable. Ship it.
What goes wrong: In the real product, the bus runs through a longer cable, past noisy power regulators, at 60°C ambient. The bus capacitance is higher, the rise times are slower, noise coupling is worse, and the whole thing falls apart intermittently.
The fix: Test your bus under worst-case conditions:
- Maximum bus length with all devices populated
- Temperature extremes your product will see
- While other circuits are switching (motors, wireless radios, switching regulators)
- At the fastest clock speed you plan to use
Use a scope to verify rise times, signal integrity, and noise margins. A logic analyzer shows you protocol correctness, but a scope shows you the electrical reality.
Quick Reference: I2C Design Checklist
| Item | Check |
|---|---|
| Pull-up value calculated for actual bus capacitance? | ✅ |
| Total bus capacitance under 400 pF? | ✅ |
| Level shifters where voltages differ? | ✅ |
| Bus routed as daisy chain, not star? | ✅ |
| Pull-ups placed centrally or at both ends? | ✅ |
| Clock stretching handled by master? | ✅ |
| Tested at max speed, max length, worst-case temp? | ✅ |
A Note on I2C Addresses
One more thing that trips people up: I2C address conflicts. Each device on the bus needs a unique 7-bit address. Many sensors come with a fixed address or only two address options (set by a pin). If you need two identical sensors on the same bus, you might be stuck.
Solutions: use an I2C multiplexer, pick sensors with configurable addresses, or put them on separate I2C peripherals if your MCU has more than one.
When to Just Use Something Else
If you're running into multiple issues here — long buses, many devices, mixed voltages, high speed — it might be time to consider SPI or UART instead. I2C is great for short-distance, low-speed communication with a few devices. It's not great for everything.
Check out our I2C vs SPI vs UART comparison for a detailed breakdown of when each protocol makes sense.
Want to get your pull-up resistor values right the first time? The I2C Pull-Up Calculator handles standard mode, fast mode, and fast mode plus — just enter your bus capacitance, voltage, and target speed.