• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 5399 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.

PCA9515A signal spikes in I2C chain

Konstantin Sumenko60
Prodigy 210 points
Other Parts Discussed in Thread: PCA9515, TCA9517

Hello I'm facing a signal distortion in my i2c chain:

PCA9515 is used to split large i2c tree into several branches. The branch2 also uses level translator GTL2010BS to work with 1.8V levels. 

The branch1 works well: i can address and read-write to devices, and oscillograms are clean (counting 0.5V low levels from PCA). But when I try to read from I2C SLAVE in a branch2 I get a acknowledge failure on byte send right after correct address transfer.

The oscillogram from TP1 (TP2 is the same) give a clue (red-scl, yellow-sda, I2C speed 100k, address then byte1):

After an address receive I2C SLAVE gives an ACK on sda line and right after ACK deassertion we can see a spike on SCL line:

This spike is interpted by I2C slave as a next SCL clock pulse, so slave shifts a data bit on in and the next transactions are shifted by one bit. The next ACK (on data byte transfer) arises one SCL cycle before it needs to - I2C MASTER doesn't see it on a real place and returns an ACK error.

If I ommit a PCA9515 from I2C chain (shorting BRANCH2 to BRANCH1) - the BRANCH2 starts to work. 

Howhever I want to make a buffer work correct. What is a nature of these SCL spikes (they are following aright after I2C slave pulls SDA to real zero), is it the process of switcing SDA gate from output to input inside PCA9515 when the slave answeres, but why the SCL reacts on it? How can this spike can be filtered: may be a series resistors in a SCL and SDA lines (making pull-ups stronger wont help)?

Best Regards, Konstantin.

  • 0
    TI__Genius 16450 points

    Hello Konstantin,

    Thank you for the waveforms.

    At first glance, I feel that there might be something going on with the GTL2010 when the slave releases the bus. The PCA9515 states in the description that two PCA9515s may not be used in series due to the hysteresis used on the inputs.

    Would you be able to try communicating directly to a slave device that is 3.3V tolerant and bypassing the GTL2010? I have a feeling that with 2 different buffers being used, the hysteresis of the inputs might be causing this.

    You state that you have a large i2c tree, are you using the PCA9515 on any of the other branches to communicate with a 3.3V tolerant slave? Does that branch exhibit similar behavior?

    If you are looking for a i2c buffer that is capable of communicating directly with a 1.8V slave, I would suggest taking a look at the TCA9517, which is capable of level translation as well as i2c repeating.

  • 0 in reply to Jonathan Valdez
    Prodigy 210 points
    Hello, Jonathan!
    I'm not able to bypass a GTL2010, cause all the slaves on its side are not 3.3V tolerant. PCA9515 is only used in a 1.8V branch (cause one half of a tree is 1.8V - another is 3.3V).

    The GTL2010 itself uses pass transistors and without buffer in series gives clear waveforms with good edges and good low level voltages ( ~50mV offset).

    Howhever, I think it will be better to use suggested TCA9517 omitting GTL2010. Thanks!