First the pull-ups: I2C lines are open-drain, so without pull-up resistors to VDD the lines can never reach a high level and the bus simply can't function, this is the single most common dead-I2C cause. With power off I'd measure the resistance from SDA and SCL to VDD to confirm pull-ups exist and are a sane value (a few kΩ), and with power on I'd scope the lines to see if they idle cleanly at VDD. If pull-ups are present and the lines still won't go high, suspect a device holding a line low, a slave stuck mid-byte holding SDA, or a short, and try the bus-recovery trick of clocking SCL up to nine times then issuing a STOP. I'd also verify every device is actually powered and shares a common ground, and that I'm addressing a device that's really on the bus (an address typo or conflict). The discipline is to scope the lines rather than re-read the driver, because a dead bus is almost always electrical: missing pull-ups, no power/ground, or a stuck line, not a software bug.
Communication Protocols · Interview question
An I2C bus is completely dead, no device responds. What do you check first?
A strong answer
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
Common Bus Bugs
A field guide to why a bus is dead, garbled, or flaky: pull-ups, baud/clock mismatch, drive contention, and wiring faults, plus a symptom→cause table and a scope-first method.