TCA9555: I2C Timing Requirement Criterion

Actually we concern this is a design issue, so need help to clarify.

Thanks!!

Hi Sirs,

Thanks for your quick reply.

So, may I know what the rise time of I2C with 1k pull up and a 50 pF load capacitor on your test is?

Like... 500ns? 800ns? or??

Moreover, how does TI make sure that rise time should not be influenced TCA9555 if the rise time is approximately 1000ns? 

Like...have report or any document?

Thanks!!

Shu,

"So, may I know what the rise time of I2C with 1k pull up and a 50 pF load capacitor on your test is?"

I don't have access to that information but with that kind of loading you should expect the rise time to be about 42 nanoseconds measured from 70% of Vcc to 30% of Vcc.

"how does TI make sure that rise time should not be influenced TCA9555 if the rise time is approximately 1000ns? "

I looked at the internal design of this device. SCL only has an input stage to the device which goes through a ESD structure. The input buffer is a gate for CMOS FETs. There nothing which can influence the rise time from this other than parasitic capacitance.

"Like...have report or any document?"

Please refer to the document below to understand how rise time is affected and how to control rise time.

Thanks,

-Bobby

Hi Sirs,

Thanks for your reply.

We know the timing is from the I2C standard.

We would like to know does TI have test this spec internal?

If yes, have any report can share?

Thanks!!

Hi Sirs,
Sorry for pushed, have any update on this?
We would like to know how does TI to define this 1000ns spec??
Because we under this spec (around 800 ns) but our BMC always send error message.
Thanks!!

Hi Sirs,
Update our test.
If we change 2k on SCL, SDA use original resistor, our BMC will passed.
If we change 2k on SDA, SCL use original resistor, the BMC still send error message.
If change to use NXP PCA9555ㄝ and use original resistor on both side (SCL/SDA), our BMC will passed (the rise time is 800ns).
So, have anything we missed?
Do you have any idea on this case?
Could you share TI how to define this 1000ns spec?

Thanks!!

Hello Shu,

"We would like to know does TI have test this spec internal?"

We do not screen the devices for the timing requirements. Tests were done prior using a device which shared the same digital core as this device and the results were the device passed all timing requirements with flying colors (incredibly well). I have been working with the FAE who manages the customer you have been asking for. I have provided the content(documentation) you asked for to him. I cannot provide this data here as it requires an NDA. 

"Could you share TI how to define this 1000ns spec?"

Defined from I2C standard as the maximum.

Data I found showed 400pF loading and 10pF both will provide ACKs even up to 1100ns at Vcc 1.6V and 5.5V at both cases of -40C and 85C.

Even in your case, our device is meeting the requirement of being below 1000ns. There is no issue here on that, I assume you are asking from a assurance standpoint here that anything below 1000ns will work.

"Do you have any idea on this case?"

This issue seems to be a coding problem where you are getting false negatives. From the information you have provided, it seems our device still works but it is your BMC which just thinks something is wrong.

"If change to use NXP PCA9555ㄝ and use original resistor on both side (SCL/SDA), our BMC will passed (the rise time is 800ns)."

I would suggest trying to make the rise time for the PCA9555 to something similar to what our device was seeing like 860ns or 900ns and seeing if the BMC considers this a failure.

-Bobby

Hi Bobby.

We got your test result, thanks!!

We have change the NXP PCA9555 at same condition, the rise time us 860ns, our BMC didn't send any error message.

So, is possible to do long-time validation, because this issue doesn’t appear at each read/write condition, it happens at low probability.

For example, our BMC read/write TCA9555 per second, but this issue only appears one time around 15 ~ 30 minutes.

Hey Shu,

"BMC didn't send any error message." Is the BMC telling you the problem is because of the rise time or is it possible there is something else going on and you assume the issue is the rise time? (because you can get 100% passes by making the rise time fast with the pull up resistor?)

"So, is possible to do long-time validation, because this issue doesn’t appear at each read/write condition, it happens at low probability."
We can set something up to do this but how long do you need us to run the test for? Does failure occur with 100% of the devices or is there also a lower fail rating?

Thanks,
-Bobby

Hi Sirs,

Thanks for your reply.

"BMC didn't send any error message." Is the BMC telling you the problem is because of the rise time or is it possible there is something else going on and you assume the issue is the rise time? (because you can get 100% passes by making the rise time fast with the pull up resistor?)

Yes~after we change the fast rise time the fail phenomenon 100% be fixed.

"So, is possible to do long-time validation, because this issue doesn’t appear at each read/write condition, it happens at low probability."
We can set something up to do this but how long do you need us to run the test for? Does failure occur with 100% of the devices or is there also a lower fail rating?

Of course we need occur with 100% of the devices test if possible.

We also need to know how many read/write time that will meet the fail phenomenon . (like if read/write 10000 times will meet first fail phenomenon....)

Shu,

I've created a test set up and code to test and tried running it today but for some reason I am having issues. I think it is related to the buffer I am using. I will try again tomorrow with a different buffer and get back to you.

"Does failure occur with 100% of the devices or is there also a lower fail rating?

Of course we need occur with 100% of the devices test if possible."
^ it seems you misunderstood what I am trying to ask. When YOU test and see failure. Do you see the issue on all boards or just a few?

-Bobby

Hi Sirs,

Thanks for your reply.

We can see this problem on all our boards.