Interview Question · Debug

Recovering a Stuck I2C Bus

L2 Mid-LevelL3 Seniori2cbus clearrobustness

The interviewer asks

After a watchdog reset of the SoC, the I2C bus is dead: SDA reads low forever, SCL is high. What happened and how does the controller recover?

log

Illustrative post-reset pin observations
Controller reset released
SCL=1, SDA=0
SCL=1, SDA=0
No new START can be issued

Reveal the Model Answer

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.

How a Bus Gets Stuck: The Controller Resets Mid-ReadMeasured: the controller reads register 0x00 (data 00h) and resets three bits into the byte. 200 ns per column.

Cycle 5
The target is sending 00h: it pulls SDA for every bit. The controller makes the clock.
Cycle 45
SCL rises for the third data bit, and the controller resets. It lets go of both lines.
Cycle 60
Nobody clocks any more. The target waits for an SCL fall that never comes and keeps pulling: after the reset: scl 1, sda 0, tdl 1.

Measured. Nobody broke a rule; the bus is half a transaction, and only a controller with a clock can finish it. Every controller that wakes up now sees SDA low and thinks the bus is busy.

Nine Clocks at Most: The Target Lets Go After 5Measured: ctrl.bus_clear(cleared) on the stuck bus above. 250 ns per column.

Cycle 4
The controller pulls SCL low: the falling edge the target was waiting for. It moves on to its next bit, another 0.
Cycle 9
Each pulse lets the target shift out one more bit. The controller checks SDA while SCL is high.
Cycle 55
After 5 pulses the byte is done and the target lets go for the acknowledge slot. SDA rises.
Cycle 64
The controller stops pulsing and sends a STOP, so every device's bus logic is idle again.

Measured: I2C CLEAR PULSES 5 STOP 1 CLEARED 1 TIMEOUT 0, and the next register read works: I2C S 50 W A 3c A Sr 50 R A 3c NA P.

RUNIcarus Verilog · in your browser

Edit the code, then run it

Expected: data 08 at bit 6, bus clear: pulses 3, STOP seen 1, SDA 1 PASS: bus free, STOP seen data 00 at bit 7, bus clear: pulses 8, STOP seen 1, SDA 1 PASS: bus free, STOP seen

`timescale 1ns/1ns
// The controller reset in the middle of a read. The target is still sending `data` and has bit
// `bit_i` on SDA. It moves to the next bit at every falling SCL edge; after bit 0 it lets go for
// the acknowledge slot. The rebooted controller either tries a plain STOP, or a bus clear: up to
// nine SCL pulses, stopping as soon as SDA reads high, then a STOP. With SCL high, the
// controller pulls SDA low and lets go: a START (every device resets on it), then a STOP.
module tb;
  logic c_scl_low = 0, c_sda_low = 0, t_low = 0;
  wire scl = !c_scl_low;
  wire sda = !(c_sda_low | t_low);
  byte data; int bit_i, stops;
  always @(posedge sda) if (scl) stops++;
  always @(negedge scl) if (bit_i >= 0) begin
    bit_i--;
    #100 t_low = (bit_i >= 0) ? !data[bit_i] : 1'b0;   // bit_i < 0: the ACK slot, SDA released
  end
  always @(negedge sda) if (scl) begin bit_i = -1; t_low = 0; end   // START: the target resets its bus logic
  task automatic stop_cond;              // SCL is high here: pull SDA low, then let it rise
    #200 c_sda_low = 1; #600 c_sda_low = 0; #600;
  endtask
  task automatic stuck(input byte d, input int b, input bit clear);
    int pulses = 0;
    c_scl_low = 1; #100 data = d; bit_i = b; t_low = !d[b];   // mid-byte, SCL low
    #500 c_scl_low = 0;                // the controller resets and lets go of SCL
    stops = 0; #1000;
    if (clear) while (sda == 0 && pulses < 9) begin
      c_scl_low = 1; #1300 c_scl_low = 0; #1200 pulses++;
    end
    stop_cond;
    if (clear) $display("data %h at bit %0d, bus clear: pulses %0d, STOP seen %0d, SDA %0d", d, b, pulses, stops, sda);
    else $display("data %h at bit %0d, STOP only: pulses %0d, STOP seen %0d, SDA %0d", d, b, pulses, stops, sda);
    if (stops == 0) $display("FAIL: no STOP formed, SDA is still held low");
    else $display("PASS: bus free, STOP seen");
    t_low = 0; bit_i = -1; #2000;
  endtask
  initial begin
    stuck(8'h08, 6, 1);
    stuck(8'h00, 7, 1);
    $finish;
  end
endmodule

Self-Check

Tick each key point you covered in your answer.

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

What Interviewers Listen For (Mid-Level)

A good mid-level answer finds a target stuck in the middle of sending a byte. It knows the nine-clock recovery of UM10204 section 3.1.16 and why each pulse helps.

Cross-Questions

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItBreak ItScale It

Recovering a Stuck I2C Bus
WhyWhy up to Nine ClocksL2 Mid-Level
Why does the bus clear use up to nine clocks, and why stop early?

Reveal the Model Answer

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.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Every falling SCL edge moves a stuck transmitter to its next bit. Key point 2 Within a byte's eight bits and its acknowledge slot, it must reach a 1 or the ACK slot. Key point 3 There it lets go of SDA, so nine pulses cover any position. Key point 4 Stop as soon as SDA reads high. Key point 5 Extra pulses after that just clock a target further into a transfer the controller no longer wants.

What Interviewers Listen For (Mid-Level)
A good mid-level answer explains that each clock edge moves the stuck target one bit forward. Eight data bits plus the ACK slot give the limit of nine.
- Lesson P8.8Stuck Buses, Bus Clear and Resets
- Problem P8.8.1Recover a Stuck SDA with at Most Nine Clocks
What IfSDA Still Low After Nine ClocksL2 Mid-Level
What if SDA is still low after the nine clock pulses?

Reveal the Model Answer

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.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Then the target is not just waiting for clocks; it may be hung. Key point 2 Stop pulsing and report the failure. Key point 3 UM10204 then points to the device's hardware reset input, or a power cycle to trigger its power-on reset.

Misconception

"Keep sending clock pulses until SDA goes high."

Nine pulses cover every bit position. A target that has not let go by then will not let go for more clocks.

Source NXP UM10204 rev. 7 §3.1.16 Bus clear
- Lesson P8.8Stuck Buses, Bus Clear and Resets
- Problem P8.8.1Recover a Stuck SDA with at Most Nine Clocks
What IfWhen SCL Is the Stuck LineL2 Mid-LevelL3 Senior
Now SCL is stuck low instead of SDA. Does the nine-clock trick help?
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Your level

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

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.

What to Do When the Bus Is StuckArrows lead from the symptom to the remedy; read SDA and SCL first.

SDA stuck
Clock the stuck target through the rest of its byte, then STOP (§3.1.16).
Nothing helps
If SDA is still low after nine pulses, or SCL itself is held, only a hardware reset or a power cycle clears it.

Read the diagram as text
SDA low, SCL high: a target mid-byte
SCL low: a device holds the clock
Up to nine clocks: stop when SDA reads high
STOP: every device idle again
HW reset or power cycle: the mandatory POR
SDA low, SCL high → Up to nine clocks
Up to nine clocks → STOP: SDA free
Up to nine clocks → HW reset or power cycle: still low
SCL low → HW reset or power cycle

Read SDA and SCL first. Clock pulses help only when SDA is stuck; a held SCL needs a hardware reset or power cycle.

Self-Check
Tick each key point you covered in your answer.
Key point 1 No. Key point 2 The controller cannot make SCL pulses if something holds SCL low. Key point 3 UM10204 says to use the devices' hardware reset inputs. Key point 4 Or cycle their power to trigger the mandatory power-on reset. Key point 5 So the controller must detect the fault with a time-out and report it. Key point 6 The board also needs a reset path to the I2C devices, a system design decision made early.

What Interviewers Listen For (Mid-Level)
A good mid-level answer says clock pulses are impossible when SCL is held. It names a hardware reset or a power cycle as the fix.
- Lesson P8.8Stuck Buses, Bus Clear and Resets
- Problem P8.8.2Why Nine Recovery Clocks Never Arrived
Break ItBugs in a Bus-Clear RoutineL2 Mid-Level
Name the bugs you have seen, or would expect, in a bus-clear implementation.

Reveal the Model Answer

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.

Self-Check
Tick each key point you covered in your answer.
Key point 1 One bug sends only eight pulses, one short for a target that needs nine. Key point 2 Another sends no STOP after SDA comes back, so devices still think a transfer is open. Key point 3 A third pulses without reading SDA, so it claims success while the line is still low. Key point 4 A fourth waits forever when SCL is held, instead of timing out. Key point 5 Each needs its own stuck-target scenario to show up.

What Interviewers Listen For (Mid-Level)
A good mid-level answer lists at least three bus-clear bugs, each with the test that exposes it.

Scale ItSigning off an I2C ControllerL3 SeniorL4 Staff

Walk me through your verification plan for an I2C controller and target pair. How do you know you are done?

Reveal the Model Answer

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.

Checking with only…	What escapes
Write then read back	Wrong-address ACK, pointer wrap, stretch and arbitration faults, short bus clear
One controller	Arbitration and loser faults
Data checks only	Hold-time, tBUF and missing-STOP faults
Wire timing checker only	Most logic faults that keep legal timing

Self-Check

Tick each key point you covered in your answer.

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

What Interviewers Listen For (Senior)

A good senior answer names several layers of checking and links each kind of fault to a stimulus. Its checker works out the target's state from the wires, never from the design's internal signals.

Prove ItSolve P8.8.1: Recover a Stuck SDA with at Most Nine ClocksSimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem P8.8.1

What People Get Wrong

Common wrong answers and why they fail. Run It shows the wrong belief failing on a real simulator.

Misconception

"Just send a STOP after the reset to free the bus."

A STOP is SDA rising while SCL is high. With the target holding SDA low, the controller cannot make it rise. The twin tries it on the same stuck target as the run: no STOP, SDA still 0.

Run It

RUNIcarus Verilog · in your browser

Edit the code, then run it

Expected: data 08 at bit 6, STOP only: pulses 0, STOP seen 0, SDA 0 FAIL: no STOP formed, SDA is still held low

`timescale 1ns/1ns
// The controller reset in the middle of a read. The target is still sending `data` and has bit
// `bit_i` on SDA. It moves to the next bit at every falling SCL edge; after bit 0 it lets go for
// the acknowledge slot. The rebooted controller either tries a plain STOP, or a bus clear: up to
// nine SCL pulses, stopping as soon as SDA reads high, then a STOP. With SCL high, the
// controller pulls SDA low and lets go: a START (every device resets on it), then a STOP.
module tb;
  logic c_scl_low = 0, c_sda_low = 0, t_low = 0;
  wire scl = !c_scl_low;
  wire sda = !(c_sda_low | t_low);
  byte data; int bit_i, stops;
  always @(posedge sda) if (scl) stops++;
  always @(negedge scl) if (bit_i >= 0) begin
    bit_i--;
    #100 t_low = (bit_i >= 0) ? !data[bit_i] : 1'b0;   // bit_i < 0: the ACK slot, SDA released
  end
  always @(negedge sda) if (scl) begin bit_i = -1; t_low = 0; end   // START: the target resets its bus logic
  task automatic stop_cond;              // SCL is high here: pull SDA low, then let it rise
    #200 c_sda_low = 1; #600 c_sda_low = 0; #600;
  endtask
  task automatic stuck(input byte d, input int b, input bit clear);
    int pulses = 0;
    c_scl_low = 1; #100 data = d; bit_i = b; t_low = !d[b];   // mid-byte, SCL low
    #500 c_scl_low = 0;                // the controller resets and lets go of SCL
    stops = 0; #1000;
    if (clear) while (sda == 0 && pulses < 9) begin
      c_scl_low = 1; #1300 c_scl_low = 0; #1200 pulses++;
    end
    stop_cond;
    if (clear) $display("data %h at bit %0d, bus clear: pulses %0d, STOP seen %0d, SDA %0d", d, b, pulses, stops, sda);
    else $display("data %h at bit %0d, STOP only: pulses %0d, STOP seen %0d, SDA %0d", d, b, pulses, stops, sda);
    if (stops == 0) $display("FAIL: no STOP formed, SDA is still held low");
    else $display("PASS: bus free, STOP seen");
    t_low = 0; bit_i = -1; #2000;
  endtask
  initial begin
    stuck(8'h08, 6, 0);
    $finish;
  end
endmodule

See the Fix

`timescale 1ns/1ns
// The controller reset in the middle of a read. The target is still sending `data` and has bit
// `bit_i` on SDA. It moves to the next bit at every falling SCL edge; after bit 0 it lets go for
// the acknowledge slot. The rebooted controller either tries a plain STOP, or a bus clear: up to
// nine SCL pulses, stopping as soon as SDA reads high, then a STOP. With SCL high, the
// controller pulls SDA low and lets go: a START (every device resets on it), then a STOP.
module tb;
  logic c_scl_low = 0, c_sda_low = 0, t_low = 0;
  wire scl = !c_scl_low;
  wire sda = !(c_sda_low | t_low);
  byte data; int bit_i, stops;
  always @(posedge sda) if (scl) stops++;
  always @(negedge scl) if (bit_i >= 0) begin
    bit_i--;
    #100 t_low = (bit_i >= 0) ? !data[bit_i] : 1'b0;   // bit_i < 0: the ACK slot, SDA released
  end
  always @(negedge sda) if (scl) begin bit_i = -1; t_low = 0; end   // START: the target resets its bus logic
  task automatic stop_cond;              // SCL is high here: pull SDA low, then let it rise
    #200 c_sda_low = 1; #600 c_sda_low = 0; #600;
  endtask
  task automatic stuck(input byte d, input int b, input bit clear);
    int pulses = 0;
    c_scl_low = 1; #100 data = d; bit_i = b; t_low = !d[b];   // mid-byte, SCL low
    #500 c_scl_low = 0;                // the controller resets and lets go of SCL
    stops = 0; #1000;
    if (clear) while (sda == 0 && pulses < 9) begin
      c_scl_low = 1; #1300 c_scl_low = 0; #1200 pulses++;
    end
    stop_cond;
    if (clear) $display("data %h at bit %0d, bus clear: pulses %0d, STOP seen %0d, SDA %0d", d, b, pulses, stops, sda);
    else $display("data %h at bit %0d, STOP only: pulses %0d, STOP seen %0d, SDA %0d", d, b, pulses, stops, sda);
    if (stops == 0) $display("FAIL: no STOP formed, SDA is still held low");
    else $display("PASS: bus free, STOP seen");
    t_low = 0; bit_i = -1; #2000;
  endtask
  initial begin
    stuck(8'h08, 6, 1);
    $finish;
  end
endmodule

Prints: data 08 at bit 6, bus clear: pulses 3, STOP seen 1, SDA 1 PASS: bus free, STOP seen

Missed Corner

"Send a general-call software reset (06h)."

Sending it needs a working bus, which is exactly what is missing. Software reset is also optional, so many targets ignore it.

Source NXP UM10204 rev. 7 §3.1.14 Software reset; Table 3

Spec Misquote

"UM10204 says nine clocks then a STOP."

§3.1.16 asks for nine clock pulses and a hardware reset or power cycle if that fails. Ending with a STOP is good practice that restores a clean bus state, not a sentence in the spec.

Source NXP UM10204 rev. 7 §3.1.16 Bus clear

Find Your Next Track

Put Your Skills to Work

Prepare to Explain Your Thinking

An Idea to Try? Pick a Tool.

Recovering a Stuck I2C Bus

Your Answer

Self-Check

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Cross-Questions

Your Answer

Self-Check

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Your Answer

Self-Check

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Your Answer

Self-Check

What Interviewers Listen For (Senior)

What Interviewers Listen For (Staff)

What People Get Wrong

Learn It, Then Prove It

The Question

Your Answer

Self-Check

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Cross-Questions

Your Answer

Self-Check

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Your Answer

Self-Check

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Your Answer

Self-Check

What Interviewers Listen For (Senior)

What Interviewers Listen For (Staff)

What People Get Wrong

Learn It, Then Prove It