Does clock speed matter when recovering from I2C bus lock up?

Question

When there is I2C lock caused by slave device driving the SDA line low you need to manually generate a few clock signals by doing a simple bit banging on the SCL pin. I thought that this need to be done with the same frequency as the I2C communication was running before the lock up but it also works for me if I do a bit banging with a much lower frequency. Let's say I have I2C clock speed configured to be 100kHz, then I have a lock up and I generate a few clock signals with a frequency of 4kHz and immediately I2C is working fine again. Please explain if the frequency of bit banging does matter when unlocking I2C bus.

Answer 1

Does clock speed matter when recovering from I2C bus lock up?

Simple answer: No.

Detailed answer: As you know, slaves are not programmed to run at a specified frequency because SCLK is generated and "served" by the master. To ensure proper resetting, just refer to the timing diagram shown in the datasheet (i.e. minimum hi- and low-pulse duration).

After 9 or 10 clock pulses, slave should send an ACK and release the SDA line. If not then a hardware reset or power-cycle (God forbid!) may be required.

Answer 2

It seems your problem is that some IIC bus slave is holding SDA low when it shouldn't.

Your solution is to give the slave clock pulses until it finally lets go of SDA. These are ordinary clocks from the slave's point of view. You can use whatever clock speed the bus and that slave can support.

As soon as the slave releases SDA, do a bus start to reset the message decoding logic of all slaves.

Something bad happened to get into this mess in the first place. Either the slave is buggy or there were data or clock errors on the bus so that the slave received something the master didn't send. Both are serious problems. If the latter, you probably have noise on the bus and/or are trying to run it too fast for the pullups and capacitance on the bus.