• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1012 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCA9554A: TCA9554A tsp Timing fail

Paul Yeh
Genius 14755 points
Part Number: TCA9554A
Other Parts Discussed in Thread: BQ35100,

Hi team,

My customer is doing EDVT testing in their project, they found the MCU I2C (EFR to I/O Expander ) communication timing can not meet the spec. 
See below pictures for details . Please help to double check if it is acceptable. And looking forward to your feedback.

Thanks

The tsp: spike timing diagram.

And customer's testing at 400kHz clock. The tsp is around 382ns that is larger than 50ns

testing at 100kHz. The tsp is around 412ns that is larger than 50ns

  • 0
    TI__Guru 59510 points

    Hi Paul,

    This looks like a data line handoff after the 8th clock pulse (ACK) which is basically a handshake from slave to master. In this case, the master is giving up control of the data line (purple signal begins to rise) and then the slave is pulling down on the data line (purple line falls) to ACK its slave address call to the master. I don't consider this a violation of spec since this is not a random signal integrity issue/noise but rather communication hand off that is expected in I2C.

    This is okay and will not cause signal integrity issues between a master/slave or other slave devices on the bus.

    -Bobby

  • 0 in reply to BOBBY
    TI__Genius 14755 points

    Bobby,

    Thanks for replied. But currently customer is highlight this tsp is out of specification, so I don't know how to convince this timing is ok.

    Thanks

     

  • 0 in reply to Paul Yeh
    TI__Guru 59510 points

    If we want to be specific here, the master is required to hold the dataline low for 300ns based on the denotation [3] of table 10 on page 48 of the I2C spec V2.6

    "A device must internally provide a hold time of at least 300 ns for the SDA signal (with respect to the VIH(min) of the SCL signal) to bridge the undefined region of the falling edge of SCL."

    If the customer wants to resolve this, they must add a 300ns or longer hold time on the ACK transaction before the master releases the bus. Since the delta is about 400ns based on your scope shots, I would suggest a hold time of 500ns.

    In my opinion though, this isn't necessary since it won't cause signal integrity issues and is a common oversight in most systems.

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 150 points

    BOBBY said:

    If we want to be specific here, the master is required to hold the dataline low for 300ns based on the denotation [3] of table 10 on page 48 of the I2C spec V2.6

    "A device must internally provide a hold time of at least 300 ns for the SDA signal (with respect to the VIH(min) of the SCL signal) to bridge the undefined region of the falling edge of SCL."

    If the customer wants to resolve this, they must add a 300ns or longer hold time on the ACK transaction before the master releases the bus. Since the delta is about 400ns based on your scope shots, I would suggest a hold time of 500ns.

    In my opinion though, this isn't necessary since it won't cause signal integrity issues and is a common oversight in most systems.

    -Bobby

    Hi Bobby

    Thanks for your explain.

    But there are some unclear for me, if our master tHD:DAT doesn't meet the spec, why are the other two I2C slave device not have a spike time. One of them is BQ35100,which is TI's Gauge IC ,another one is ALS sensor.

    We just want to get the reason why it is happened in TCA9554A.

    Anyway , it's glad to your support.

    Thanks,

    Jay

  • 0 in reply to Jay zhu
    TI__Guru 59510 points

    Hi Jay,

     That means that the other 2 slaves are driving the dataline low earlier than our device. From my understanding, the I2C spec does not state when an I2C slave must drive the line low in regards to an ACK. Only that the ACK occurs 250ns/100ns (standardmode/fastmode) before the rising clock edge {defined as data set-up time}.

    -Bobby