SN65DSI83: I2C problem

Hey Jorge,

Can you send me the schematic for the SN65DSI83. Id like to have a look at the pull up resistors used and if the MCU you're using has pull ups as well. The very well could be some form of push pull that is happening so the SN65DSI83 cannot pull back up. 

Is this issue replicated across multiple SN65DSi83 chips?

Hi Vishesh,

This is the schematic of our VLS:

We directly connect the SN65DSI83 to "I2C_L" side, and processor is connected to "I2C_H" side.

VL is 1,8V and VH is 3,3V.

In processor side we have 4,7K external pull-ups to 3,3V.

We have this problem in all our prototypes, 20units.

Hi Vishesh,

we have the same schematic specified in datasheet:

The capacitor is not connected to SDA or SCL.

We have checked the values of pull-up resistors in both sides and they are ok, 4K7.

Hey Jorge,

Could you send the script file and the physical setup for the DSI83? I'm going to try to recreate the issue using the DSI83 EVM and help debug.

Hi Vishesh,

I only try to download the values of its registers continuously in a while bucle:

while true; do i2cdump -f -y 1 0x2c; done

Regarding to the physical set-up:

• iMX8Plus using its MIPI-DSI interface and I2C number 2 of its processor  configured at 3,3V
• I2C2 iMX8Plus <-> PCA9306 <-> DSI83.
• LVDS side of DSI83: it doesn´t matter. I2C fails with the LCD Screen connected or disconnected.
• Regarding to I2C baudrate. It fails earlier at 400KHz than 100KHz. But with boths baudrates always fails with that bucle (between a few seconds and 10 minutes).

I see, I will try to get a sample of the PCA9306 and get a similar test setup. I will provide an update by end of week next week. 

Ok, thanks!

If you need more information, let me know it.

Hi Vishesh,

We have removed PCA9306 in our PCB, and in its placed we have introduced the IC TCA9517 using wire wrappings (because it has not the same pinout). It is another VLT with a different structure.

We have stressed DSI83 using the same method (reading the values of its registers continuously in a while bucle):

while true; do i2cdump -f -y 1 0x2c; done

And we have reproduced  the same failure. Therefore we think that the problem is not the PCA9306.

Hey Jorge, 

Yeah based off your results the it seems the issue wasn't the PCA9306. Have you tried implementing a small delay in the while loop after every read. My theory is that the I2C line is being overloaded due to the constant polling. try implementing a 10ms sleep time after each I2C dump. 

Hi Vishesh,

this bucle is for try to reproduce quickly a failure in I2C. We have a problem with this I2C in our equipment. It appears after 30 minutes, 1 hour, ... Therefore the bucle is not a normal mode operation, it is used for reproduce the problem.

We have stressed other I2C buses with this kind of bucle during 24h aprox. and they works fine. We only have the problem with this I2C and this slave.

Best regards.

Is this an issue that you have seen across multiple DSI83 chips or is it just this one?

Hi Vishesh,

The problem appears in all 25 prototypes that we have. 

Best Regards

Hey Jorge,

This seems to be a more complex issue than I originally thought. I want to double check every step of the setup of your device, so please bear with me. 

1) Can you confirm that you are following the initialization sequence found in the DSI83 datasheet:

2) Can you confirm the I2C initialization on the scope. It should look like this:

3) Also just confirming you are unable to get an ACK from the DSI83 over I2C after it crashes correct?

Hi Vishesh!

1) We are going to check it, but we are using your driver. Therefore I suppose that it is correctly implemented.

2) We can try but it is complicated due to we have not test point in ENABLE pin and obviosly not in MIPI interface.

3) Yes, I don´t why SDA is put always at "0" state when it crashes:

If I disable DSI83 with "ENABLE" pin, I2C-SDA recover its "1".

What is the SDA connected to? It is being connected to anything other than the pull up and your interface to read and write?

It is connected in this way:

iMX8Plus processor (I2C2 configured at 3,3V) <-> Slave1 at 3,3V (we have remove it for testing the problem).

                                                                          <-> VLS (PCA9306, we tested with other VLS reproducing the same problem). 3,3V <-> 1,8V

                                                                                              <-> Slave2 at 1,8V (we have remove it for testing the problem).

                                                                                              <-> DSI83 at 1,8V.

So would this diagram be correct?

Also I noticed that on your schematic you don't have SDA and ACL pulled up to 1.8 but rather 3.3V, and the net names seem to be mismatched.

 Can you try adding a 4.7K resistor from the SDA lane to 1.8V and see if is that works?

Your diagram is correct. There are 4,7K PU resistors in both sides (3,3V and 1,8V):

Inside of this green BOX:

In other part of our schematic we connect the 1,8V I2C to DSI83:

Ok it seems that the circuitry is in place correctly as well. Can you confirm the setup and hold times for the 1.8V and 3.3V? there could be a delay in the voltage conversion that violates the I2C timing requirements. 

Hi Vishesh,

The 1,8V and 3,3V voltages comes from PMIC, therefore I assume that it is OK.

Hey Jorge,

Is there any way you can validate that?

It seems there is a slight timing issue due to the overloading test of the I2C lines you are doing. From my understanding the chip is being brought up correctly and the I2C lines are electrically sound. The only other possible issue is the I2C data being sent, and any alteration of the signal. i.e. the 3.3V to 1.8V step. Regardless of how accurate the power delivered by the PMIC is, there will be a slight delay in the voltage conversion. My theory is that this delay is violating some of the I2C timing requirements.