I2C Interview Questions

Each device can only pull a line low or let go. A pull-up resistor raises the line when every device lets go. So the line is the wired-AND of all devices, and two drivers never fight. That makes clock stretching, clock synchronisation and multi-controller arbitration possible. It also lets parts on different supplies share a bus. The cost is the rising edge: a resistor charges the bus capacitance, which limits speed and bus size.

The first time another device pulls SDA low while this one drives high, two outputs fight. In simulation the line resolves to x. On a board, the two transistors set a voltage, often between VIL and VIH, so receivers disagree. ACKs, arbitration and the controller's own bits all break. The fight can also damage drivers.

Two bounds. Rp(max) comes from the rise-time limit: tr = 0.8473 Rp Cb. With 300 ns and 100 pF, Rp is at most about 3.5 kΩ. Rp(min) comes from the sink current: (VDD − 0.4 V) / 3 mA, about 967 Ω. Pick inside that window, toward the high end if supply current matters. At 400 pF in Fast-mode the window is empty, so a resistor alone cannot work.

UM10204 lists four options. Run a slower SCL so the rise fits, or use higher-drive parts, such as Fm+ devices, with a stronger pull-up. Split the bus with buffers, multiplexers or switches so each segment stays under the limit, or add a switched pull-up. Buffers add delay to every edge and may bring their own VIL/VOL rules. Fm+ still stops at 550 pF and 1 MHz.

No. A digital checker measures edge-to-edge times such as tLOW, tHIGH, tSU;DAT and tBUF on 0/1 pins. Rise time, fall time, spike width and bus capacitance are analog. In RTL the pins switch instantly, so a pull-up that is far too weak still passes. Those rows need SPICE or a board measurement, plus the pull-up arithmetic.

The controller makes all nine clocks. In the ninth, the transmitter releases SDA. The receiver pulls it low (ACK) and holds it through the high phase; SDA left high is a NACK. On a write the target ACKs, and on a read the controller does. The controller NACKs the last read byte so the target stops driving. An ACK would tell the target to send the next byte, which may hold SDA low and block the STOP.

After an address, most likely no device answers at that address, or the target is busy with a real-time task. Later in a transfer, a NACK can mean the target did not understand the byte or cannot take more. A controller-receiver also NACKs on purpose to end a read. Whatever the reason, the controller ends with STOP or tries again with a repeated START. Software decides whether to retry.

A correct controller that sends a 1 and reads a 0 decides it lost arbitration. So the log says "arbitration lost", even on a single-controller bus. The wires alone cannot say who pulled. You need the driver view, meaning each device's pull-low enable. It shows the target's lane still active after the ninth clock.

The transmitter drives it. On a write, it is odd parity from the controller: the XOR of the eight data bits with 1. Parity lets the target detect a corrupted byte. On a read, it is end-of-data from the target: 0 ends the message, and 1 offers more. So the target decides how much it returns, though the controller may abort after a 1 with a repeated START.

It cannot NACK the byte, because the ninth bit belongs to the controller. Error type S2 says the target ignores the rest and waits for a STOP or a repeated START. The controller sees nothing on the wire. It learns of the error later, from the Protocol Error bit that GETSTATUS returns.

A target that needs time holds SCL low. SCL is a wired-AND, so the line stays low after the controller lets go. The controller must read SCL back, and start timing its HIGH only once SCL really is high. A controller that times HIGH from its own release samples SDA too early. The target still holds the clock, so the controller reads a wrong byte. Stretching is optional for targets and has no time limit in I2C.

On a wired-AND SCL, every controller starts counting LOW when the line falls. But the line rises only when the last one lets go. Each waits for SCL high before counting HIGH, and the first to finish HIGH pulls it low again. So the bus clock gets the longest LOW and the shortest HIGH of all controllers. A stretching target is just another device with a long LOW.

I2C sets no limit, so the controller IP should carry its own configurable time-out. It should give up and report, not hang. With SCL stuck low, clocking out is impossible, so UM10204 points to a hardware reset input or a power cycle. To verify, use a target model that never releases. Check that the controller times out, flags the error and leaves SCL released.

Any target whose datasheet allows a longer stretch. I2C sets no limit on stretching, so a 1 ms limit turns legal behaviour into a reported error. Set the limit from the slowest target's datasheet. Use SMBus's 35 ms only when the system really uses SMBus devices.

No. In I3C only the controller drives SCL, and legacy I2C targets on an I3C bus may not stretch. The controller may stall instead, holding SCL low in only four places. They are the ACK/NACK slot, a write's parity bit, a read's T-bit and the first bit of an assigned address in DAA. The absolute maximum stall is 15 ms.

Both drive SDA bit by bit, and compare the wired-AND line with what they sent while SCL is high. The first controller to send a 1 and read a 0 has lost, and it releases SDA at once. Until then both sent identical bits, so nothing is lost and the winner's message is intact. Address 0x58 loses on the fourth address bit. The loser may clock to the end of that byte, and retries when the bus is free.

It must switch to target mode at once and keep decoding the address. The winner may be addressing this very device. If it waits as an idle controller until the bus is free, it misses its own address. The winner then sees a NACK. Separately, it must not drive any more bits of its own message.

It must wait until the bus is free. The bus counts as busy from the START until a set time after the STOP, and a repeated START keeps it busy. So the loser waits for the winner's STOP and the bus-free time. A START any earlier breaks the winner's message.

Yes. UM10204 leaves three collisions undefined while arbitration is still running. In two of them, one controller sends a repeated START or a STOP while the other sends a data bit. In the third, one sends a repeated START against a STOP. Arbitration works only when both still send bits in the same position of the same format.

Build a two-controller bench with a reference controller and the DUT on wired-AND lines. Cover a loss at every address and data bit position and identical messages that complete together. Add a loss while addressed as a target, the clock-to-end-of-byte rule, and unequal LOW/HIGH periods for synchronisation. Check from the driver view that the loser never drives after losing. Back it with a formal proof on an abstraction.

The frame is S, 0x50 with W, ACK, the pointer 0x3C, ACK. Then comes a repeated START, 0x50 with R, ACK, the data byte, NACK, STOP. The write sets the target's internal pointer, and the read returns data from it. The repeated START changes direction without releasing the bus. A STOP would free the bus. On a multi-controller bus, another controller could then take it and move the pointer before the read.

After the STOP and the bus-free time, another controller may win the bus. It may access the same target, move its pointer or change the register. Your read then returns data from the wrong place, with no error anywhere. STOP then START works on a single-controller bus, with a target that keeps its pointer. Sr makes it safe without relying on either assumption.

The target does not detect the repeated START. It treats the Sr and the next address byte as more write data, and never answers the read address. So the controller reads the released line: 0xFF. UM10204 requires devices to reset their bus logic on any START or repeated START, and expect an address. A test that only writes, or reads with STOP plus START, never exercises it.

A combined-format read: write the register pointer, send Sr, send the read address, then read. Check that the target ACKs the read address and returns the register value, not 0xFF. Cover Sr in the monitor, so coverage shows that this format really ran.

The address takes two bytes: 1111 0XX plus W, then the low eight bits. Here XX are the top two address bits. Several targets may ACK the first byte, but only one ACKs the second. After the pointer write, the controller sends Sr and repeats only the first byte, with R. The target that matched both bytes earlier stays addressed and answers.

Sample data at SCL rises, and detect START and STOP as SDA edges while SCL is high. Close the current transaction at a repeated START or a STOP. A monitor that publishes at START publishes the previous transaction late. On the first START, it publishes a byte it shifted in before the address. Treat Sr as both the end of one transfer and the start of the next.

The controller reset in the middle of a read, while a target was sending a 0. The target waits for SCL edges to finish its byte. No STOP can form while it holds SDA low. To recover, clock SCL up to nine times, checking SDA before each pulse. Each falling edge moves the target to its next bit, and it lets go at a 1 or its ACK slot. Then send a STOP, and if SDA stays low, use a hardware reset or power cycle.

Every falling SCL edge moves a stuck transmitter to its next bit. Within a byte's eight bits and its acknowledge slot, it must reach a 1 or the ACK slot. There it lets go of SDA, so nine pulses cover any position. Stop as soon as SDA reads high. Extra pulses after that just clock a target further into a transfer the controller no longer wants.

Then the target is not just waiting for clocks; it may be hung. Stop pulsing and report the failure. UM10204 then points to the device's hardware reset input, or a power cycle to trigger its power-on reset.

No. The controller cannot make SCL pulses if something holds SCL low. UM10204 says to use the devices' hardware reset inputs. Or cycle their power to trigger the mandatory power-on reset. So the controller must detect the fault with a time-out and report it. The board also needs a reset path to the I2C devices, a system design decision made early.

One bug sends only eight pulses, one short for a target that needs nine. Another sends no STOP after SDA comes back, so devices still think a transfer is open. A third pulses without reading SDA, so it claims success while the line is still low. A fourth waits forever when SCL is held, instead of timing out. Each needs its own stuck-target scenario to show up.

I use four kinds of checking, starting with data checks against a model derived from the wire. The others are a timing checker for the Table 11 edge times, a driver-view checker and a two-controller bench. Directed programs target each fault: wrong addresses, pointer wraps, Sr, stretching, collisions and a stuck bus. Done means every seeded fault is caught, legal variations stay silent and coverage closes.