I2C specification clarification: mixing transaction to different targets

[danielholala]

Hi,

I'm seeking clarification on the I2C specification UM10204. 

If a controller I2C device is communicating with a first I2C target (S, Addr1+w)  and then  - instead of continuing the communication  with the first target - starts communicating with second I2C target (S, Addr2+r/w), how will the first target device handle this? Will it be able to take up the transaction when the controller addresses it again?

For example if a target device specifies a transaction as follows:

<S><Addr,w><Data><Data><S><Addr,r><data><P>
                                               ^

Can the transaction be interrupted here ^ and, e.g.,  <S><Addr2,w><data> inserted?

One could argue that the transaction with first target is not carried out to specification and not cleanly terminated by Stop condition. However, if first target ignores all messages to other I2C addresses, the transaction is complete.

I could not find anything in the I2C specification regarding this situation. All I found was this note:

"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 target address, even if these START conditions are not positioned according to the proper format."

And comments are appreciated.

Thanks.
Daniel

[rajvel1988]

Hello NXP Team, 

I have a few Question on the NXP I2C Specification. can you please help on this.

I have referred to the I2C specification, Specification says for standard mode ( 100KHz) and Fast mode ( 400KHz).

In our Application, we are using less than 100KHz . Do we need to consider the same Rise time mentioned for 100KHz?  We are operating at  50kHz. What would be the acceptable Rise time ? how to calculate the rise time / Fall time  requirement when we operate at different frequencies on the I2C ?.

2. In one scenario, we are operating at 12.5KHz and observed that the Hold time. I am not sure whether this hold time acceptable or not . can you please check and confirm 

[JozefKozon]

Hi Daniel,

please also refer to the section 3.1.4 in the UM10204.

With Best Regards,

Jozef

[JozefKozon · Accepted solution]

Hi Daniel,

both cases described by you are possible. Depends on, if the slave allows repeated START. Please see a section 8.11.2 in PCF8523. 

In case of PCF8523 the STOP bit has to be released.

Please see a section 2.1.2 in slva704 attached. 

To what part number are you referring to?

With Best Regards,

Jozef

[danielholala]

Dear @JozefKozon ,

Thank you for your response.

I did not know that there are I2C target devices which do not support repeated start conditions. Thanks for pointing this out. I was under the impression that repeated start condition was a mandatory I2C-bus protocol feature. The specification UM10204 is silent about it (e.g., table 3.1 does not list repeated start condition separately).

So obviously, there are devices that require separate write-read transfers (i.e., write register address, read data from this register) with each transfer terminated by a stop condition.

That being said, the PCF8523 seems to allow repeated start conditions at least for write transfers (see page 47, Fig.32 and related text).

You asked about the devices I had in mind: it's a generic EEPROM, like 24LC32 or PCF85102. Obviously these devices support repeated start conditions but it's unclear from the datasheets whether write-read transfers have to be done in one combined transaction.

Thanks.
Best regards,
Daniel

[JozefKozon]

Dear Daniel,

thank you for pointing out to the statement in the page 47. Seems, that one of the statements in the PCF8523 datasheet are not completely correct. Either the one on the page 45. "For this device, a repeated START is not allowed. Therefore, a STOP has to be released before the next START." or the one on the page 47. "data transfer is terminated by sending either the STOP condition or the
START condition of the next data transfer."

I will report it to the application team.

Regarding the PCF85102C, the repeated start seems to be allowed.

The 24LC32 doesn't clearly state if the repeated start is allowed.

With Best Regards,

Jozef

[JozefKozon]

Dear Daniel,

the application engineer confirmed, that repeated start is not allowed for PCF8523. Please see below.

DESCRIPTION

The statement in page 45 is correct which “repeated START condition is not allowed to be used in I2C communication with PCF8523."

The statement is page 47 should be changed as “In the write mode, a data transfer is terminated by sending the STOP condition, and then following the START condition of the next data transfer”

With Best Regards,

Jozef

[AFeatureOrABug]

Hi Jozef,

What is the implication of using a double start with the PF8523? What symptoms will manifest? We are using a linux driver and it is sending the double start (see attached), however, the response from the PCF8523 appears intact. The question is whether we have to rebuild the linux driver or this will work always? 

[danielholala]

Dear Jozef,

Thank you for keeping in touch.

I consider this as another indication that it's always best to follow datasheets closely. That brings me back to my original posting. My lesson learned: If I see a combined write/read transfer in a datasheet that uses a repeated start condition:

the recommendation is to execute this transfer in one go and not to interrupt this transfer by a second transfer to a second target.

Thanks for your help.

Best regards,
Daniel