6 Resolving a Stuck Bus

SDA being stuck low is problematic when information is required to be read or data needs to be transmitted across the bus. There are several possible methods to unstick a bus. If the system designer of the bus has access to modifying or building the software of the processor or host on the bus, they can be able to code the processor or host to look for a potential stuck bus and react to try to resolve it. For an I2C bus, this can be done by toggling the serial clock line (SCL) eight to sixteen times and then issuing a stop condition. This can push the I2C device’s state machine that is holding the serial data line (SDA) low through its process flow and reset its state machine to an idle state releasing the bus. For the SMBus, the SCL line can be held low for longer than the t_timeout, which can force all SMBus devices to all reset and resolve the stuck bus. If the I2C target devices have a dedicated reset pin, a processor on the bus can initiate a reset to unstick the bus. This however is not an efficient design if there are a large number of I2C target devices. The processor can be forced to reset all target devices connected to this reset pin, therefore causing the re-initialization of all I2C targets on the bus, although only one device caused the stuck bus condition in the first place.

From a hardware approach, using an I2C buffer device with hot insertion protection can be used to remedy a stuck bus resulting from a hot insertion event. TCA9511A and TCA4307 include dedicated logic to separate the non-powered I2C bus (daughter card) to the powered I2C bus (backplane) until both sides are ready to be connected, preventing glitches on the bus. This safe connection mechanism is provided in more detail in I2C Solutions for Hot Swap Applications, application note.

To try to resolve a stuck bus from crosstalk, EMI, or a bad power on reset, the TCA4307 can be designed into an I2C bus as it includes an additional feature called stuck bus recovery. The stuck bus recovery feature can detect if the SDA line is stuck low. If the device is stuck low for longer than 40ms (t_stuckbus), it then disconnects the downstream I2C bus from the upstream I2C bus and drives the RDY pin LOW. This lets the processor know that the downstream channel has been disconnected from the bus. This prevents the upstream bus, where the I2C controller/processor typically resides, from getting stuck and allows it to continue communicating to other I2C devices on the upstream bus segment. The TCA4307 then can generate up to sixteen clock pulses until the SDA line unsticks. The TCA4307 can then issue a stop condition to attempt to reset the I2C device’s state machine to its idle state. If the stuck bus is resolved, the TCA4307 can reconnect the downstream bus and the upstream bus automatically.

This can be seen in the figure below. Channel 1 (blue) is the SCL line, channel 4 (green) is the SDA line, channel 3 (purple) is the RDY pin which signifies when the downstream bus and upstream bus are connected together again. Figure 6-1 shows an example where the bus gets unstuck by the TCA4307 after 6 clock pulses and then TCA4307 controlling the SDA line to issue a stop condition.

Figure 6-1 Waveform Example of the Stuck Bus Recovery Feature