I2C Timing on the Bench: Rise Time, Pull-Ups, and Probe Traps
Most I2C failures are not protocol bugs. They are a rise time that misses the spec, a pull-up chosen by habit, or a probe that adds enough capacitance to change the measurement it is taking.
Quick Answer
- Rise time: tr ≈ 0.8473 × Rp × Cbus. 4.7 kΩ with 200 pF is 796 ns — fine at 100 kHz, out of spec at 400 kHz.
- Pull-up window: Rp max from rise time, Rp min from sink current. At 3.3 V, 3 mA, the floor is about 0.97 kΩ.
- 400 kHz: 300 ns max rise, 400 pF max bus. Both limits bind at once on a long cable.
- Measure at 30–70 %, at the worst-case device, with a short ground — and remember the probe adds 10–15 pF.
1. The limits by mode
| Mode | Clock | tr max | Cbus max | tSU;DAT min |
|---|---|---|---|---|
| Standard | 100 kHz | 1000 ns | 400 pF | 250 ns |
| Fast | 400 kHz | 300 ns | 400 pF | 100 ns |
| Fast Plus | 1 MHz | 120 ns | 550 pF | 50 ns |
| High Speed | 3.4 MHz | 40 ns | 100 pF | 10 ns |
These come from the NXP I2C specification (UM10204) and its timing tables. The two numbers that matter for a board are tr and Cbus, and they are linked by the pull-up.
Why the bus behaves the way it does
I2C is open-drain: every device can pull a line low, and nothing can drive it high except the pull-up resistor. That is what makes multi-master arbitration and clock stretching possible, and it is also why the rising edge is an RC curve rather than a driven edge.
The consequence is asymmetric timing: falling edges are fast (a transistor pulls down), rising edges are slow (a resistor charges the bus). Every timing problem on an I2C bus is therefore a problem with the rising edge or with the resistor that creates it.
The acknowledge bit is the other timing-sensitive part: the receiver must pull SDA low within the ACK window after the eighth clock, and the master must release SDA in time. On a slow bus with a weak pull-up, the ACK can arrive late enough to be read as a NACK.
2. Rise time and the pull-up
tr ≈ 0.8473 x Rp x Cbus 4.7 kOhm, 100 pF: 0.8473 x 4700 x 100e-12 = 398 ns 4.7 kOhm, 200 pF: 796 ns 2.2 kOhm, 200 pF: 373 ns 1.8 kOhm, 200 pF: 305 ns
At 100 kHz, 4.7 kΩ is fine up to about 250 pF. At 400 kHz it fails above about 75 pF — which is reached by three devices plus a short cable, before any margin.
Two details change the real number. Resistor tolerance: a 1 % part is fine, a 5 % part moves tr by 5 % and is usually still acceptable. Temperature: pull-up resistance drifts slightly, but device input capacitance and cable capacitance drift more, which is why the check should be repeated at the temperature extremes rather than only at 25 °C.
3. The pull-up window
Rise time sets the maximum resistance; sink current sets the minimum:
Rp max = tr / (0.8473 x Cbus) Rp min = (VDD - VOL) / IOL = (3.3 - 0.4) / 0.003 = 967 Ohm
That is the reason 400 kHz designs use 1.5–2.2 kΩ, not 4.7 kΩ. It is also why "it works on the dev board" is not evidence: the dev board has three devices and 8 cm of trace, and the product has six devices, a connector and 40 cm of cable.
Choosing the resistor for a real bus
Given: 400 kHz mode, Cbus = 200 pF, VDD = 3.3 V Rp max = 300 ns / (0.8473 x 200 pF) = 1.77 kOhm Rp min = (3.3 - 0.4) / 3 mA = 0.97 kOhm Choose 1.5 kOhm: tr = 254 ns, sink current = 1.9 mA
This is a valid design, and it is nothing like the 4.7 kΩ that appears on most reference schematics. Those schematics assume 100 kHz and a short bus; copying them into a 400 kHz product is the most common way to inherit a timing problem.
| Bus capacitance | Rp max, 100 kHz | Rp max, 400 kHz | Practical choice |
|---|---|---|---|
| 100 pF | 11.8 kΩ | 3.5 kΩ | 4.7 kΩ |
| 200 pF | 5.9 kΩ | 1.8 kΩ | 1.5–2.2 kΩ |
| 300 pF | 3.9 kΩ | 1.2 kΩ | 1.2 kΩ, check IOL |
| 400 pF | 2.9 kΩ | 0.9 kΩ | Below the floor: reduce speed |
4. What the scope is actually showing
Measure 30–70 %, not 0–100 %
I2C rise time is specified between 30 % and 70 % of VDD, because the bus is an RC network and the tails are asymptotic. Measuring 0–100 % gives a number that is roughly 1.5–2× too large and makes a compliant bus look marginal.
The probe is part of the bus
A standard 10:1 probe adds 10–15 pF. That is 5 % of a 200 pF bus and enough to push a marginal design over the limit. Worse, the ground lead adds inductance: a 10 cm clip lead is roughly 100 nH, which rings with the bus capacitance and shows overshoot that the real bus does not have.
Practical rules: use a spring ground or a soldered coax pigtail; measure at the device furthest from the master; probe SCL and SDA separately, not both with two long leads; and state the probe capacitance when you report a rise time.
If you must probe a fine-pitch board, solder a 0.1 mm wire to the pin and clip the probe to that, rather than resting the tip on the pad. The mechanical contact is more stable, and the added capacitance is a known 12 pF instead of a value that changes with pressure.
5. Setup and hold are relative to the clock edge
Two measurement mistakes here. First, measuring at the master: the data seen by a slave at the end of a long bus arrives later, and the setup margin is smaller there. Second, forgetting that SDA is bidirectional: during an acknowledge, the slave drives it, and the edge shapes are different.
For fast mode, tSU;DAT is 100 ns and tHD;DAT is effectively 0 with 300 ns internal hold. Those numbers are easy to meet on a short bus and easy to lose on a long one with a weak pull-up.
Clock stretching needs its own measurement
If a slave stretches the clock, SCL stays low after the master releases it. Measure that directly: trigger on the falling edge and confirm the line does not rise until the slave releases it. A master that does not support stretching will clock straight through and corrupt the read, and the symptom is a NACK or a byte of 0xFF — which looks like a wiring problem.
6. Bus capacitance budget
A typical fast-mode board: six devices at 8–10 pF each (50–60 pF), 8 cm of trace at about 1 pF/cm (8 pF), connector and cable (50–150 pF), probe (12 pF). The cable is usually the largest single term, which is why long I2C runs need a bus buffer or a lower speed.
Two practical consequences. First, the cable, not the devices, is the variable you can control — shorten it, or shield it, or accept 100 kHz. Second, the budget must be computed for the worst-case configuration the product supports, not the bench configuration: a board with a header for an external sensor has to tolerate the user's cable, not the developer's 10 cm one.
If the numbers are close, add margin to the resistance rather than reducing it: a slightly slower edge is safer than a pull-up that cannot sink enough current at VOL.
7. Failure patterns and what they mean
A representative case
A board with six devices, a 30 cm cable and 4.7 kΩ pull-ups works at 100 kHz and fails at 400 kHz with a NACK from the last device. The instinct is to blame the device or the firmware. The measurement shows a 1.1 µs rise time at the far end — nearly four times the 300 ns limit — and the cause is the cable capacitance plus the 4.7 kΩ.
Two fixes are possible: reduce the pull-up to 1.5 kΩ (rise time falls to about 350 ns with 400 pF, still marginal), or drop to 100 kHz where the same bus is compliant. A third option, a bus buffer, splits the capacitance and lets the fast mode work. Which one is right depends on whether the transfer time matters.
| Symptom | Usual cause | Measurement that confirms it |
|---|---|---|
| NACK on the last device only | Rise time too slow at the far end | tr at the furthest device vs mode limit |
| Works at 100 kHz, fails at 400 | Pull-up too large for Cbus | tr and Rp; check the window |
| Random bit errors under load | Crosstalk or ground bounce | Scope both lines with a short ground |
| Bus stuck low after a reset | Slave holding SDA, or no clock stretching support | Count clocks; check the slave state machine |
| Intermittent after adding a device | Capacitance budget exceeded | Recompute tr with the new total |
8. A measurement procedure that holds up
- Power the board from its real supply, with the real cable and the real number of devices.
- Set the bus to the fastest mode the product will use, then add 20 % margin in the analysis.
- Probe at the device furthest from the master, with a short ground.
- Capture SCL and SDA; measure tr between 30 % and 70 %, on both edges.
- Measure tSU;DAT at the receiver, using the SCL threshold crossing as the reference.
- Record the probe capacitance next to the number; a rise time without it is not reproducible.
- Repeat at the lowest and highest operating temperature, because pull-up resistance and driver strength both drift.
| Check | Pass | If it fails |
|---|---|---|
| Rise time at worst device | ≤ 300 ns (400 kHz) | Reduce Rp or Cbus |
| Pull-up current at VOL | ≤ 3 mA | Raise Rp; check VOL spec |
| Acknowledge on every device | ACK at address + 1 | Address conflict or missing pull-up |
| Clock stretching | Master waits while SCL held low | Master lacks support; use a different peripheral |
| Temperature extremes | Same margin at −20 and +70 °C | Recompute with worst-case Rp tolerance |
For the pull-up sizing itself, the companion guide on I2C pull-up resistors covers the resistor selection in more detail. Our PCA9535 IO expander is a typical 400 kHz device to test against.
A simple report format keeps the numbers honest: mode, clock, Cbus estimate, Rp, tr measured (30–70 %), probe capacitance, temperature, and the device position. Without those seven values a "the bus is fine" claim cannot be checked by anyone else.
For incoming inspection of I2C devices — date codes, marking, and lot checks — see our traceability process.
9. FAQ
Why does my bus work on the bench but fail in the field?
The field bus has more capacitance: longer cable, more devices, a connector. Rise time scales with capacitance, so a design that was marginal at 200 pF fails at 350 pF.
Can I just lower the clock to 100 kHz?
Often yes, and it is a legitimate fix when the bus is long. It doubles the transfer time, which matters for large transfers but is irrelevant for a sensor poll.
How do I measure rise time correctly?
30 % to 70 % of VDD, at the far end of the bus, with a short ground and a known probe capacitance. Report the probe capacitance with the number.
Do I need a bus buffer?
If the capacitance exceeds the mode limit, yes — a buffer splits the bus into segments. For 400 kHz over long cables, a buffer or a lower speed is usually the only reliable option.
Why does adding a device break an existing bus?
Each device adds input capacitance and, if it has weak drive, changes the edge shape. Recompute the rise time and the pull-up window with the new total.
Is 4.7 kΩ always wrong for 400 kHz?
Not always, but it is only compliant at low capacitance — roughly 75 pF or less. Most boards with a connector exceed that.
How do I know the bus capacitance without measuring it?
Add it up: device input capacitance from the datasheets, trace at about 1 pF/cm, cable from its specification, plus 12 pF for the probe. It will be within 20 %, which is enough to choose a resistor.
10. Sources
- NXP, UM10204: I2C-bus specification and user manual — timing tables and rise-time limits by mode.
- Texas Instruments, I2C Bus Pullup Resistor Calculation (SLVA689) — Rp max/min derivation.
- Texas Instruments, High-Speed Layout Guidelines (SLLA414) — probing and return-path practice.
Debugging an I2C bus?
Send the number of devices, cable length and current pull-ups. We will compute the rise time and tell you whether the bus is inside the mode limits.
