• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 4 answers
  • Subscribers 35 subscribers
  • Views 409 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TCA9539-Q1: SDA issue

Lanxi Li
Expert 6845 points
Part Number: TCA9539-Q1
Other Parts Discussed in Thread: TCA9539

Hello team,

My customer test TCA9539-Q1, but found that there is noise at SDA pin which is in cycle.

Noise's cycle 24us, keep 340ns, max voltage can reach 2.3V, the appearing time is near ACK.

Would you mind help check whether this is related TCA9539 and have any advice here.

Best regards,

Lanxi

  • 0
    TI__Mastermind 48308 points

    Hi Lanxi,

    This looks to be expected behavior of the ACK bit. This is the transition from the master handing off the I2C bus to the slave device (TCA9539) so the IO expander can ACK the bus letting the master device know that the communication was received well. 

    The spike is formed from master releasing the bus. Then, the pull-up resistance pulls the voltage high towards VCC. The blue signal also has an "RC like" curve showing that the bus capacitance and the pull-up resistor is pulling up the voltage to VCC. Before the voltage on SDA can rise fully, the slave device (TCA9539) ACKs the bus and drives the signal low, forming the spike that is shown.

    Regards,

    Tyler

  • 0 in reply to Tyler Townsend
    TI__Expert 6845 points

    Tyler,

    Is there any risk for this noise if it exist?

    And also, is there any way to solve this noise issue?

    Best regards,

    Lanxi 

  • 0 in reply to Lanxi Li
    TI__Guru 73971 points

    Hi Lanxi,

    This isn't noise. This is the SDA hand off that occurs after the 8th/9th falling edge of the clock. This is normal/expected behavior and is acceptable in I2C standard because it is occurring during the low period of the clock.

    -Bobby

  • 0 in reply to BOBBY
    TI__Expert 6845 points

    Bobby

    Okay, understand, thank you so much. I will send this to the customer to see whether they have more questions.

    Thank you.

    Lanxi

  • 0 in reply to Lanxi Li
    TI__Expert 6845 points

    Hello Bobby,

    We double check the I2C timing request of TCA9539 as below.

    The spike time should be under 50ns, but in customer's test, the spike on SDA will last 340ns which is over 50ns.

    Please help double confirm the understanding and risk here.

    Thank you so much.

    Lanxi

  • 0 in reply to Lanxi Li
    Guru 317370 points

    These are different kinds of spikes.

    The I²C specification requires that spikes with a duration less than 50 ns must be ignored by the receiving device.

    This spike is longer, and will not be removed by the 50 ns filter. However, the state of the SDA line is ignore while the SCL line is low, so this spike has no effect anyway.

    As Bobby said, such spikes normally happen when one device stop pulling the line low, and the other device starts pulling the line low. There is no required timing for this situation, so it can happen that both pull the line low for some time, or that none pulls the line low for some time; the only requirement is that the SDA line must be stable when the rising edge on SCL happens.

  • 0 in reply to Clemens Ladisch
    TI__Mastermind 48308 points

    Hi Lanxi,

    As Clemens suggested, the 50ns spike timing in the I2C standard is referring to the 50ns de-glitch filter present in I2C devices. This 50ns de-glitch filter is responsible for filtering out ("throwing away") signal anomalies that are 50ns long. This helps the master/slave devices to determine whether the signal is an actual rising edge, or if the signal is some inductive noise (spike) that is a false rising edge. This ensures that the receiving I2C device does not sample data falsely due to seeing a false rising edge on the SCL line. You can imagine that if I2C devices did not have the 50ns deglitch filter, the devices could see potential ringing on the SCL line causing the receiving I2C device to sample bad data due to seeing rising edges that appear on the SCL line. 

    This is a separate case apart from the original question asked about the ACK/NACK bit that is shown by the blue signal in the scope capture provided. This is the SDA handoff between a master and slave device when determining the state of the 9th bit (ACK/NACK). 

    The "spike" happening on the SDA at 340ns is okay, and is normal/expected behavior. 

    Regards,

    Tyler