1

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/

  1. 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.

  2. Is there any other way in addition to the what is explained above to cause a bus hang?

  3. Can such a problem be caused by software driver?

ultimate cause
  • 111
  • 1
  • 4
  • 7
    Anything that will pull either of the I2C lines down (when it should not) will block the bus. As simple as this. – Eugene Sh. Jan 15 '18 at 18:39
  • 3
    @EugeneSh., recommend you convert comment to answer, there's not a lot more to it. – TonyM Jan 15 '18 at 18:46
  • 1
    It's also worth pointing out that I2C and SMBus are different. IIRC, SMBus has a time limit on clock stretching that isn't in I2C. So an I2C bus can hang and actually be compliant, while SMBus can't. – The Photon Jan 15 '18 at 19:41
  • @EugeneSh - Thanks. I think understand that part - however I don't get it what would cause a line to be permanently pulled down - and then what makes it to release it. – ultimate cause Jan 16 '18 at 01:17

1 Answers1

3

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.

supercat
  • 45,939
  • 2
  • 84
  • 143
  • Thanks for your effort, however I am new to electronics and I2C both. Can you please clarify on "In that scenario, the first clock would advance past the ack, and the next eight..". What is "first clock" in the context and what is "next eight"? Also if you could answer how this could be caused by a software driver? (Inopportune reset?) – ultimate cause Jan 16 '18 at 03:10
  • In spite of your best attempt, the second part for multiple slave case is also somewhat obscure to me. Two slaves releasing bus at different times causes hang? How two slaves can start responding simultaneously, as the address may have matched only one? – ultimate cause Jan 16 '18 at 03:34
  • 1
    @ultimatecause: The potential problem situation would be if the master somehow outputs a clock pulse which doesn't meet the minimum pulse width spec, with the effect that one slave sees it and the other doesn't. Depending upon how sensitive the slaves are to different pulse widths, it may be very unlikely that such an issue might occur. On the other hand, if it does occur, recovery may be impossible. – supercat Jan 16 '18 at 15:48