I2C bus recovery

With normal devices start followed by stop should reset state of the bus. Howere, to send start we need SDA high. If this is bus with single master SDA should be high at least at the end of byte (bus should flat high as device waits for ACK).

I am not sure if this helps: writer is supposed to stop seeing new start, so it is not clear if extra clock give anything for writers. OTOH, if bus is clocked reader could get wrong data, so it seem better to reset bus as soon as possible (that is first time when SDA is high).

Well, I plan to do so. But I do not like to use untested code, and to preperly test it I would need special driver to inject various upsets to I2C bus.

Do you think that a slave transmitting 0xFF interrupts the transmission in the middle as soon as it detects a falling transition on SDA (STOP)?

Anyway, in this case the STOP transmission is necessary after reading SDA high. I couldn't find the STOP transmission in the Linux kernel code, only a few clock cycles until SDA is detected high.

Yes, if the slave transmitting something stops after seeing a STOP (SDA going low). I don't know it this is a well-known specification and if all the I2C slaves implement this specification correctly.

What do you mean with reader? When the bus is stuck, the writer is the slave and the reader should be the master that is trying to recovery the bus, so technically it is not reading anything.

Are you thinking of a bus with multiple slaves? They shouldn't be reading anything.

Yes, this should be ideal, but it's not simple to inject errors in the I2C bus, so I asked for some ideas and suggestions.

IT is suppossed to if it meets the standard. ANY change of SDA when SCL is High resets the logic of every device on the bus in response to the Start or Stop bit just sent.

You don't need a STOP, you need either a start or stop. When you enable the I2C controller and start a transmission, it will begin with a start, and that will provide the needed reset.

It is a well known requirement of the I2C specification that any start or stop bit needs to reset the logic of devices.

Not all devices support it though, but if you have one that doesn't and you get stuck like this, your only answer is some other form of reset (like a power cycle).

This is why when Intel wanted to use I2C on their motherboards, they made and improvement to have a time out on the bus, so all devices could reset out of a hang condition. I forget the name of their version, SMbus or something like that.

If you use chips rated for their spec, they will work.

If you see low on SDA this could be writer slave sending 0 or reader slave sending ACK.

I see, anyway I was looking at an old Linux kernel code. In the actual code[1], a STOP condition is really sent before exitigin bus recovery function.

Oh yes, I thought that a slave that had started a byte transmission needed to receive 9 clock cycles to go to the end and reset its internal state-machine. From what you say, this is not true. Even when a STOP condition is detected in the middle of a byte transmissione, the I2C device should reset I2C state machine.

Of course, if this I2C slave device is transmitting 0 (keeping SDA low), it's impossible to create a STOP or START condition from the master. The master needs to send clock cycle until the slave release SDA (because the byte transmission is really finished or because it is transmitting a 1).

I had the same problem (testing error recovery code paths, and getting the "stop at the right time" working on a STM32F1), so I made a special test slave based on an AtMega88:

Together with test code on your host, and maybe a logic analyzer, this allows rapidly testing lots of error events.

cu Michael