SN65DSI83-Q1: SN65DSI83-Q1 I2C detection issue

Hi,

Can you please make sure you are following the DSI83 initialization sequence as shown below?

What is the I2C address you are using? With ADDR pin being tied low, the 7-bit I2C address is 0x2C.

Can you probe both sides of the TXB0104, can you seeing the I2C command on both sides?

Thanks

David

Hi David, 

I am trying to confirm the initialization since you mention this on a previous post. 

At the moment i am just trying to detect any I2C address from the bus and I am not receiving any ack back when I probe from 0x03 to 0x77. I do have signal on both side of the TXB0104 that I decode with an oscilloscope. The data is good and present at the pin, just no answer back

Hopefully I will be able to confirm the power up sequence properly

Thanks, and if you have other advice or question please let me know

Fred

Fred

Can you also decode the data and verify the address being sent is correct?

Thanks
David 

Hi David, 

Me and my colleage looked at the initialization but we can't detect the I2C so we don't run the initialization yet. 

At this point we would only like to be able to run the I2Cdetect command so we can see the bridge on the i2c line. we will experiement with the enable pin today trying to find what is not working on our side.

Does the clock need to be in HS mode and line in LP11 mode for the I2C to be enable and for us to able to detect the bridge? 

Thanks for your help, 

Fred

Fred

I2C’s enabled as long as EN is high -> state of DSI bus should have no impact. Did you decode the I2C address and verify the address is correct?

Thanks

David 

Hi David, 

Looking at the right address sure help, I was looking at 0x58 instead of 0x2C (8 bits instead of 7bits) as you stated above. This although doesn't fully solve the issue. If I look at the signal when it probes 0x2C I get some noise on the I2C line but no ACK as I was expecting. after a certain time, the I2C restart (where the X is in the decoder) and keep on going. I tried to manually reset the unit (shorted the cap on enable to force a 0 than let it go and I still see the same. 

Any pointers? 

(hopefully you can see this image!)

Fred

Is Channel 1 the SCL and Channel 2 the SDA? I see the transmitter sends 8 clock pulse for the I2C address of 0x2C and it is a write request. But it needs to provide a acknowledge related clock pulse (9th clock) while release the SDA line. The DSI86 will then pull the SDA low to indicate the acknowledge. Below is an I2C bus waveform as a reference.

Thanks

David

David, 

You are correct, Channel 1 is the SCL and 2 SDA (fairly clear) 

I notice that we do send 8 clock and not 9, I will see if I can get this fix and test this it again. 

Thanks for the feedback! hopefully that was our issue

Fred

Good morning David, 

I looked into this further this morning after talking with my colleage and any other address than 0x2C have 9 pulses for the clock.

On the 0x2C, the clock signal stays high after the rising edge of the 9th pulse 

I don't know if it's because of the noise/disturbance/signals that is starting at the 0 between the 8th and 9th clock pulse.

Thanks, 

Fred

Fred

Do you have any other devices on the I2C bus besides the DSI86? If you do, is it possible to remove them so the DSI86 is the only device on the I2C bus?

Do you also have a I2C controller such as the Aardvark I2C controller that you can use to access the DSI86 I2C registers?

Thanks

David 

Hi David, 

The DSI83 (I am using an 83 not 86) is currently the only device on the bus. I had another device but since it's connected via external board, I was able to remove it easily. Easier for debugging. 

I don't have an Aardvark I2C controller but I can see if I can use something else to communicate with the DSI. 

Thanks, 

Fred