Communication Protocols · Interview question

The whole I2C bus is dead, SDA or SCL stuck. How do you diagnose it?

A strong answer

Two leading causes. First, missing or wrong pull-ups: if there are no pull-up resistors, the open-drain lines can never reach a high level, so the bus reads stuck low/undefined and nothing communicates, check that each line has a pull-up to the correct voltage, and that the value suits the bus speed and capacitance (too large rounds the edges and corrupts data at speed). Second, a bus lockup where a slave is holding SDA low: this happens when a slave was reset or interrupted in the middle of outputting a byte, so it's still driving SDA low waiting for more clocks while the master thinks the bus is idle. The standard recovery is for the master to manually toggle SCL up to nine times to clock the stuck slave through the rest of its byte until it releases SDA, then issue a STOP condition to resynchronize, robust drivers do this on init. Diagnostically: scope both lines (are they idling high? is one stuck?), confirm pull-ups exist and are sized right, check the supply/ground to all devices, and verify no device is mid-transaction. If SCL itself is stuck low, suspect a shorted line or a device (or master) holding it, possibly errant clock stretching.

What a weak answer sounds like

You know the answer. Do you know what gets you dinged?

Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.

From the lesson

I2C

Many devices on two wires: open-drain SDA/SCL with pull-ups, 7-bit addressing, ACK/NACK handshaking, clock stretching, and why a missing pull-up is the classic I2C failure.

More I2C questions

Browse all 472 interview questions
The whole I2C bus is dead, SDA or SCL stuck. How do you diagnose it? | EmbeddedPrep.io