I am very new to electronics and have entered in the territory of I2C bus. Want to understand the behaviour of compliant devices as per I2C protocol specification.
One condition as per the link below is when a master controller is reset in midst of a transaction. That is to say the slave engaged does not knows what to do now.
https://www.i2c-bus.org/i2c-primer/analysing-obscure-problems/blocked-bus/
-
I do not understand how does this calls for bus hang? The master which was restarted could always start a new transaction and the slaves should be able to read it.
-
Is there any other way in addition to the what is explained above to cause a bus hang?
-
Can such a problem be caused by software driver?
Best Answer
The master cannot issue a start or stop condition while any slave is driving SCL or SDA. If there is only one slave on the bus, the worst-case scenario would be when the the master is reset just after the slave has just been issued a "read" request, was in the process of acknowledging it, and is all set to send a "0" in response. In that scenario, the first clock would advance past the ack, and the next eight would advance past the data bits, and the device would drive SDA continuously until it receives the ninth clock. After the clock goes high then low the ninth time, however, the device would float the bus (if it hadn't done so before) to look for an ack from the master.
If there are multiple slave devices, a bus could become permanently locked up if two devices both think they've received commands to read out a string of zero bytes, but (possibly because the master was reset at a time that resulted in a "runt" pulse on SCL that was long enough to be seen by one slave but not the other) the two slaves release the bus at different times when looking for acks from the master.