I2C specs question

[mpattaje]

Hi, In all I2C specs (Philips, NXP), after the data (or address) of 8 bytes, ACK is sent/received in SDA line. Once that is done, either next 8 bytes are sent OR STOP condition is done. But due to 9th clk edge coming down before a STOP condition is asserted, there is an ambiguity for slave, which reads whatever value present in SDA when next posedge SCL happens which is actually a STOP condition. My question is why that complete 9th pulse in SCL is required? Why can't we have only posedge of that and then issue STOP by only toggling SDA? I am not sure if this is already asked somewhere. Thanks, Murali

[reyes]

Hi,

Just to clarify for other person looking into this community for reference in the future, you mentioned that the data (or address) in I2C is 8 bytes long, but it is 8-bits long.

Regarding your question:

The ninth clock pulse is not used by the I2C slave, but used by the I2C master to confirm if there is proper communication with the device, this clock pulse is known as ACK or NACK.

The Acknowledge signal is defined as follows: the transmitter releases the SDA line during the acknowledge clock pulse so the receiver can pull the SDA line LOW and it remains stable LOW during the HIGH period of this clock pulse.

When SDA remains HIGH during this ninth clock pulse, this is defined as the Not Acknowledge signal. The master can then generate either a STOP condition to abort the transfer, or a repeated START condition to start a new transfer.

The data on the SDA line must be stable during the HIGH period of the clock. The HIGH or LOW state of the data line can only change when the clock signal on the SCL line is LOW, otherwise would be interpreted as a START or STOP condition:

A HIGH to LOW transition on the SDA line while SCL is HIGH defines a START condition.

A LOW to HIGH transition on the SDA line while SCL is HIGH defines a STOP condition.

Detailed information about the I2C specification can be found in the document in the following link: https://www.nxp.com/docs/en/user-guide/UM10204.pdf

Regards,

Jose

[mpattaje]

Hi Jose,

Thanks for your reply. But it doesn't have answer to my question.

If 9th clock pulse of SCL goes low before a STOP condition, just before that, slave may read SDA line as next MSb of the next byte in the 10th posedge, which is actually going to be a STOP condition. If SCL doesn't go low and STOP is produced directly, this problem won't exist. So, why do we need a complete clock pulse on SCL, instead of just a posedge?

-mpattaje

[mpattaje]

Hi Jose,

Thanks for your reply. But it doesn't have answer to my question.

If 9th clock pulse of SCL goes low before a STOP condition, just before that, slave may read SDA line as next MSb of the next byte. If SCL doesn't go low and STOP is produced directly, this problem won't exist. So, why do we need a complete clock pulse on SCL, instead of just a posedge?

-mpattaje

[reyes]

Hi,

I don’t understand the issue you are facing, can you please clarify what issue you are seen in your system?

Can you please specify which NXP part number you are using?

If an unknown condition (out of spec condition) happens during the communication without a proper termination (like a STOP condition), the bus can get stuck in an unknown stage, for which a reset would be required.

Regards,

Jose

[mpattaje]

Hi Jose,

I assume that my explanation is not sufficient. I am attaching the pic here. The 2nd pic shows the modified SCL line between ACK and STOP condition.

If SCL doesn't come down after ACK, and master directly produces STOP, there is no confusion for the slave. But in the first pic, slave can sample the SDA in the 10th posedge and think that it is the first bit of next byte. Then when it sees the STOP, it has to discard that bit. Slave design becomes complex here.  

-Murali

[mpattaje]

Hi Jose,

Thanks for your reply. I am not yet using any product now, but developing a I2C Slave VIP. My slave checks for all posedge of SCL. If the master gives a complete SCL pulse for ACK, as 9th clock pulse, then the next bit can be either MSB of next byte, OR can be a STOP condition. This is ambiguity for the slave to sample.

Therefore I am wondering why there should be a complete 9th SCL pulse for ACK, and not just a posedge followed by a STOP condition? Master can generate a STOP condition without making SLC low for the 9th pulse, right? This way there is no ambiguity for the slave. After the ACK, it can be any one of either STOP or MSB of the next byte. 

-Murali

[reyes]

Hi,

Seems like you are developing a new protocol based on I2C  but with different rules for your I2C Slave VIP, for such case you would need to develop all the testing and confirm if it works for all the I2C Masters and Slaves. We as NXP, cannot warranty the correct behavior of the I2C communication using it out of specification.

 It is our understanding that you are proposing to delete the ninth SCL pulse of the last byte and go directly to a STOP to avoid confusion to the slave, correct? This would be seen as a error in the communication since it violates the I2C communication specification.

Per I2C specification definition “Each byte must be followed by an Acknowledge bit.” … “The acknowledge bit allows the receiver to signal the transmitter that the byte was successfully received and another byte may be sent”.

If you send the STOP condition without the 9^th clock signal as in the image you send, this will be seen as a STOP condition to abort the transfer without a successful transfer of the byte (even if it successfully send the data).

Regards,

Jose

[mpattaje]

Hi Jose,

The proposal is not to remove 9th clock pulse completely, but to remove the negedge of the 9th clock pulse only. Since any sampling happens in posedge, the complete 9th pulse may not be required, only posedge is required for the master to sample the acknowledge bit. 

In the picture I have attached, there was a posedge of 9th clock, which is sufficient to sample the ACK. Then there is STOP condition. 

-Murali

[reyes · Accepted solution]

Hi Murali,

Thanks for the clarification, I guess communication is possible in the way you do it, however, I cannot warranty or recommend it since it is used out of specification and it is proven that the way it is currently done with the nine complete pulses works properly and does not cause “ambiguity for the slaves” using I2C protocol.

According to the specification it is mandatory to have all nine pulses complete.

Regards,

Jose