[SOLVED] I2C how one master know SCL stuck LOW from clock synchronization process?

Guys,

Is there any way to know SCL is tuck at LOW in clock synchronization process between 2 masters. For each master, sense the SCL bus line LOW may come from the other master SCL. Is there any timeout of SCL LOW pulse to indicate the SCL stuck LOW?

Thanks

remember, a master is the one originating the SCL, the clock line, it could do at any speed it wants (commonly 100kHz or 10us pulse or 400kHz in high speed i2c) so let's assume both masters are at 100kHz (5us HIGH and 5us LOW), when a master waits it's own 5us on the low state it release the SCL line hoping it reach high, the synchronization mode of a good master, states that after releasing the SCL line it should check if SCL indeed reached HIGH.. if not, probably the device or another master is keeping the SCL line low so it waits until the SCL goes HIGH... (which the other master could do between its own 5us pulse window)

the arbitration mode of a good master is similar, but it works with the SDA line, if the first master release the SDA to send it to HIGH, and after SCL reach HIGH (by syncronization) and if SDA is not HIGH as the first master wanted, it should change to slave mode or wait until the other master generate the STOP...

sadly there's no timeout in the i2c specs, so if by hadware error the SCL is stuck in low there's no i2c way to detect that... you must implement the timeout in your own code...

Thanks Ryu,

I'm wondering if the synchronization works in case of 2 SCLs are inverted of each other (i.e 180 degree phase difference). As the clock pulse (HIGH and LOW) counter works normally, the SCL bus line will take the later phase SCL value.

that case could not happen in a good i2C bus, in a good i2C bus, the first master to issue the START sequence (lowering SCL and then lowering SDA) will own the bus until it finish its task with the STOP sequence... the other master should detect this and wait till the STOP to try to do its own stuff...

in case both masters issue the START sequence at almost the same time (but let's say one of them will try to clock at 180°difference), the synchronization sequence will make the bus slower but effectively at most twice the time of LOW (5+5us) for the first SCL pulse but normal 5us LOW for subsequent SCL pulses (that's what the synchronization sequence is for!! it will make both internal SCL generators to fix their phase) until the arbitration sequence kicks out one of the masters....

of course all of this assumes both masters as i2c compliant, if any or both don't check for the synchronization sequence (say they try to own the bus with the START sequence and begin to spit SCL pulses indiscriminately as you think at 180° difference ) the devices will never receive a SCL pulse and will answer NAK, hopefully forcing the shameful masters to do a STOP...