Hi All I2C users,
I have been using the I2C bus in a variety of products for around 16 years. Some systems have only one slave device (an EEPROM) while others have a mix of display (LCD and LED), RAM, EEPROM, I/O, ADC/DAC, etc.

On the whole the bus has been very reliable, however I have seen occasions where extreme noise has caused the I2C bus hang with SDA = 0 and SCL = 1. From my investigations it occurred when a slave chip read transfer was aborted by a glitch that caused the master to step off the bus while the slave was still intending to send. I suspect that this might have been a glitch that occurred at the Ack/Nack time where arbitration forced the master off the bus (I never deeply invetigated why it occurred - just a method of recovery) but the slave took the next 'clock' edge to send the next bit (under proper conditions there would have been a stop (which never came)).

So, as there were no additional clock pulses to complete the transfer the bus remained stuck in this state with SDA low and SCL high.

My initialisation code used to simply ensure that SDA and SCL can be set high and low, and then generate a valid stop condition to clear any slaves.

I have since expanded my I2C initialisation code to recover from a detected hung bus. The addition is fairly simple and that is to manually clock SCL if SDA is found to be low. Ultimately SDA will come free and then a valid stop can be generated, which resets all I2C interfaces on the bus.

If more than nine clock pulses have to be issued then I consider there to be a hardware failure and report it or take some other action.

BTW: The safest way to initialise/test the bus is to set SCL = 0 (which any slave should treat as noise as at power up no slave is currently addressed, or will receive or send the next bit) and then check SDA. If SDA = 0 then issue more SCL pulses as described above, or if SDA = 1 then issue a valid stop (SDA = 0, pause, SCL = 1, pause, SDA = 1).

Hope this help! Comments welcome.

PM