I2C hold time START condition

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

I2C hold time START condition

2,271 Views
alexisj204
Contributor I

We are using the PCAL9554B and would like a clarification of its behavior whent eh I2C Hold time for the Start condition is breached.

 

Problem Summary: Due to bus delays caused by I2C isolators & buffers our SDA like sometimes goes  low ~60ns before the SCL line itself goes low. This appears to be interpreted as a START condition and causes the PCAL9554 to interpret the next data byte as an address which it will ACK if it is its own address.

The datasheet specifies a "tHD;STA hold time (repeated) START condition" of 0.6us, yet the device is acting on a START condition of only 60ns

 

Attached is an image of the SDA (green) and SCL(Blue) going to the PCAL9554, this specific event is interpreted as an START bit and the next byte (0x20) will be ACKed by the PCAL9544 as it matches its own address. We have confirmed the PCAL is the one ACKing by disconnecting it.

Our workaround has been to introduce a delay on the SDA line (spare channel of a I2C buffer), this shrinks the SDA going low just 20ns before SCL goes low, the PCAL9554 no longer see this as a START condition.

 

Questions: What is the minimum time between SDA going LOW and SCL going LOW which will be considered a valid START?  We would like to validate our workaround.

 

 

0 Kudos
Reply
4 Replies

2,262 Views
reyes
NXP TechSupport
NXP TechSupport

Hi,

Your workaround seems like an excellent solution. You seem to be doing some kind of manual clock stretching with this delay to avoid undesired START condition, this should work perfectly in your application and should not cause any problem in the future.

 

SDA Should not go LOW when SCL is HIGH because this would be seen as a START condition as you properly mentioned and as stated in the I2C Manual on section 3.1.4 (https://www.nxp.com/docs/en/user-guide/UM10204.pdf).

 

Please check Figure 26 on page 23 of the I2C User Manual (from the link above), here you can find all the timing requirements for I2C, please correct me if I’m wrong, but I believe that the parameter you are looking for is the “tHD;STA” time, correct, as you can see in Table 15 of this same document on page 22, here you will find that the “minimum time between SDA going LOW and SCL going LOW which will be considered a valid START” for Fast Mode I2C-Bus (Up to 400kHz) is 0.6us.

0 Kudos
Reply

2,251 Views
alexisj204
Contributor I

What confuses me is that  I2C standard specifies “tHD;STA” = 600ns, yet the PCAL is detecting a valid START condition with only “tHD;STA”=60ns, but “tHD;STA”=10ns is not longer valid.

 

Hence i am confused why the device seems to be accepting an invalid start condition. Ideally i would like to figure out what is the threshold between valid / invalid START condition and then test the system over extreme temperature range and confirm i am with-in those limits.

0 Kudos
Reply

2,249 Views
alexisj204
Contributor I

I guess my original questions would be:

1. Is my understanding of “tHD;STA” = 0.6us correct and the device should ignore START conditions faster than 600ns but in practise this is not enforced by devices?

2. Would empirically figuring out the devices actual minimum start condition be a reliable treshold or could this vary with temperature and production batches?

0 Kudos
Reply

2,238 Views
reyes
NXP TechSupport
NXP TechSupport

Your understanding on “tHD;STA” is correct, the PCAL9554 should not detect START conditions faster than 600ns but in practice this does not seem to be enforced, so, if this undesired condition is affecting our system, I would recommend you to add a delay to avoid it.

 

Yes, you can empirically figure out the actual minimum star condition and create a reliable threshold.

Production batches should not be behave different, but temperature may affect the behavior, I recommend you to include the temperature testing when creating your threshold.

0 Kudos
Reply