Distinguish Stuck SDA from Stuck SCL in an I2C Recovery Plan

A generic reset-and-retry loop can conceal why an I2C bus stopped and can repeat a command whose outcome is unknown. Begin recovery planning by distinguishing the actual line states. A low data line with a usable clock is a different situation from a clock line that remains low.

Use the specified distinction

NXP’s UM10204 bus-clear section describes nine clock pulses for SDA held low and a hardware-reset or power-cycle route for SCL held low when appropriate. If SDA is not released, further reset action may be needed. These are bounded recovery cases, not a guarantee that clocking repairs every fault.

Record SDA and SCL levels before changing configuration. Also record which transaction was active, the controller status and which target supplies are present. This evidence helps distinguish an interrupted transfer from an electrical fault or an intentionally extended clock-low interval.

Define ownership during recovery

Prevent another software task or controller from starting traffic while recovery owns the bus. Review the peripheral-to-GPIO transition if the implementation generates recovery clocks through GPIOs. Preserve the required electrical behavior and do not drive a line high against another device holding it low.

For a multi-controller system, recovery needs coordination beyond a single processor’s local driver. A controller cannot assume that a busy bus belongs to a failed transaction. Define how the system identifies an actual fault and obtains authority to reset or isolate the affected segment.

Track the interrupted operation

After the bus becomes idle, determine whether the target’s internal state is known. A write may have completed before the controller lost the response, or it may have stopped partway. Read back state where the device supports a meaningful check instead of blindly repeating an operation with side effects.

For a configuration register, verification may be straightforward. For a command that starts motion, clears a counter or commits data, a repeated command can have different consequences. Classify operations by retry behavior and document the recovery choice for each relevant class.

Test bounded fault cases

Use a controlled test arrangement to exercise interrupted transfers and relevant reset states. Verify that the recovery terminates, reports failure when the bus remains unavailable and restores normal peripheral configuration after success. Keep persistent electrical faults distinct from recoverable protocol state.

Retain a recovery log containing initial line state, action, result and target-state verification. The goal is a predictable response with useful evidence, not an endless loop that occasionally restores communication. A recovered bus should also leave the application in a known state before it resumes issuing commands.