• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 34 subscribers
  • Views 783 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.

TCA6416: TCA6416 about Tsp Question

GaryC
Intellectual 2605 points
Part Number: TCA6416

We use the TCA6416 in our design. There is Tsp = 0-50ns in the datasheet. May I know why the TCA6416 define this spec? Since our CPU can’t accept this spec. Do you have any idea? Thanks

BR,

Gary

  • 0
    TI__Mastermind 49040 points

    Hey Gary,

    Just to clarify, the TCA6416 is not recommended for new design and instead the TCA6416A is.

    Tsp is a parameter that is defined in the I2C standard and indicates that all I2C devices need to have a glitch filter that can filter up to 50ns of spikes (this means our device also has this filter and can attenuate up to 50ns of spikes). ALL devices need to follow this spec to be I2C compliant. If you are expecting or need a larger glitch filter, there is an app note that discusses how to implement one:



    Thanks,

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 10 points

    Hi Bobby:

    Just to synchronize our project information beneath:

    The expand IC we chose is TCA6416A, and our I2C clock is at a frequency of 99KHz,which belongs to the "standard mode" defined in the I2C protocol.

    And my questions are listed as follow:

    1) Refer to the I2C protocol, under the standard mode, there has no Tsp requirement which shown in I2C protocol as both high and low spec are NA.

    Could we ignore this Tsp parameter since our measurement of Tsp is 280ns around ?

    2) If our Tsp is so rough that exceed the requirement of a 50ns a lot, how can we inprove this spike to meet spec ?

    Sincerely

    Balling

  • 0 in reply to Balling Bo
    TI__Mastermind 49040 points
    Hey Balling,

    "Could we ignore this Tsp parameter since our measurement of Tsp is 280ns around ?"
    -What exactly does your waveform look like during those 280ns? I would need to see what it looks like before I can give you an answer.

    "If our Tsp is so rough that exceed the requirement of a 50ns a lot, how can we inprove this spike to meet spec ?"
    -I did provide an app note in my previous post which shows how to improve the glitch filter. I suggest you take a look at it. Alternatively, if you can provide a scopeshot, I might be able to see what is causing the issue and suggest a fix. (undershoots, cross talk, something else?)

    Thanks,
    -Bobby