I2C Slave detect Repeated Start

[gauthamkrishnan_r]

If a Master I2C device is communicating with a Slave I2C device and generates a Repeated Start condition and starts communicating with second Slave I2C device, how will the first Slave device detect the Repeated Start condition? Will it be able to detect the Repeated Start at all, or will it keep waiting until the Master addresses it again?

[r8070z]

It means that a START condition and repeated START condition treated in the same way and the slave address will be checked.

[gauthamkrishnan_r]

Agree, but what will be the effect of the Repeated Start on the first slave device once the Master starts communicating with second slave device? The communication with first slave device is not cleanly terminated.

[r8070z]

What do you mean as communication with first slave device is clearly terminated? How it should be done?

[gauthamkrishnan_r]

I mean a 'clean termination' is done by a Stop condition, but in the absence of a Stop condition to the first slave device (when master initiates a Repeated Start followed by slave address of another slave device), the first slave device will not be able to recognize that master's communication with it has ended.

[danielholala]

I clearly understand the situation you are describing.

I'd hope that the first slave device would ignore the transaction with the second slave device (that's what I2C addresses are for, right) and thus keep its internal state machine (unaffected by the transaction with the second slave). But I don't know for sure whether I2C supports these kind of "piecewise" transactions.

Therefore I wonder why there's no reply from NXP. I'd be happy to have an official view on this situation.

[gauthamkrishnan_r]

Does it mean my slave device will not be able to recognize that the Master has started communicating to another slave device using a Repeated Start?

[r8070z]

The I2C specs says:

I2C-bus compatible devices must reset their bus logic on receipt of a START or repeated START condition such that they all anticipate the sending of a slave address, even if these START conditions are not positioned according to the proper format.