TCA9801: Logic low not low enough

Hi Jochem,

Are there any PU resistors on B-side? If so, please remove them. 

What about PU resistors on A-side? 

Regards,

Tyler

Hi Tyler,

Thanks for your quick response and sorry for the delay in my response. I'll enable notifications.

There are 2K2 pull-ups on the A-side and none on the B-side. 

Best regards,

Jochem

Hi Jochem,

Do you have a block diagram of all that is connected to the B-side of the TCA9801? 

Do you have a scope capture of the B-side signal at the TCA9801? I want to compare the signal integrity before and after the cable. 

Does replacing the TCA9801 with a new TCA9801 fix the issue? 

Regards,

Tyler

Hi Tyler,

Only a PN7160 is connected to the B-side.

The scope capture above is from the B-side signal at TCA9801. 

Replacing the TCA9803 with TCA9802 did not fix the issue. Replacing the TCA9802 with a TCA9801 also did not fix the issue. I assume replacing this TCA9801 with another TCA9801 will also not fix the issue.

Best regards,

Jochem

Hi Jochem,

CH2 is the output of the buffer after the long cable. 

I am thinking that the 50cm cabling has some series resistance drop that is affecting the VOL at the PN1760. What is this voltage drop? 

VOLB(max) = 0.26V. Given the VIL requirements at the PN1760 chip

It looks like there should be at least 0.99 V of margin for VILB. 

Are you saying these first few bits are above this margin? 

I am not completely sure why there is higher VOL on SDA. 

When I compare to SCL, the clock waveform looks fine. VOL looks consistent across clock cycles. SDA starts off with higher VOL and then settles to a lower VOL. 

Is there any differences between the two traces? 

Regards,

Tyler

Hi Tyler,

The cause has been found. The 13.56MHz from the NFC-scanner is injected into the I2C-bus. We oversaw that the SCL and SDA lines are now in hi-Z after switching from pull-up to current-source. This is almost certainly the cause of the described behaviour. We're happy that we finally understand what's going wrong, but now we still need to fix it. Note that the horrid sight below is only the case with field active when tag is present.

We were under the assumption that using an I2C buffer was going to increase robustness, not make it more sensitive to external factors. That begs the question, what next? What do you recommend?

1. Would using the T/PCA9517 on slave-side side make sense, as shown in Figure 18 in the datasheet?
2. Are there any better suited chips, perchance?
3. We've tried to filter with ferrite beads and an R/C network, but quickly approached bus limits.

Our main goals are these;

1. Reliable I2C communication across a distance of around 1 meter, external from PCB.
2. Connected with a simple and small-form factor ribbon cable with JST connector.
3. Compatible with/transparent to other I2C-devices (preferably, but not required).

Thanks for your help so far. Best regards,

Jochem

P.S. below also the scopes at both sides of the cable. Voltage drop is negligible (which made me investigate furter).

Hi Jochem,

With the holidays approaching, responses may be delayed as team members are on leave until the New Year. We will get back to you as soon as possible, thank you for understanding.

Regards,
Jack