DS90UB949-Q1EVM: DS90UB949-Q1EVM I2C interfacing issue (No I2C data read using J20 header) without ALP tool

Hi Vikas,

You should be able to read the registers using the connected MCU without ALP connected. Can you please confirm the following? 

• Are you following the power on sequence and waiting until the device is fully power on before trying to read I2C?
• What do you mean by invalid data? Are you receiving incorrect data or is there no ACK from the 949 at all?
• Are you able to provide captures of the I2C bus showing the read attempts with and without ALP connected?

Sincerely,

Ryan

Hello @Ryan Fleetham,

Thanks for your above information.

We went ahead and things are now running well but we have a few challenges. The steps which we are now following for Serializer initialization. (MODE_SEL0 = #1 and MODE_SEL1 = #1)

1. Writing the 256 EDID Bytes using APB Control Registers (0x48, 0x0D), EDID Low Byte and Upper Bytes (0x49, 0x00), (0x4A, 0x00), and then we are writing the data using APB Write register (0x4B) and incrementing the address after writing 1-byte information. 
2. Now, we are following the power-up sequence as suggested in the Serializer datasheet. 

 After completing Initialization A, we are waiting for the TMDS clock to be stable by reading 0x0C[2] register, after that, we go next for Initialization B.
3. After that we set Slave ID, Slave Alias, and Enable Pass-through of the Serializer.

4. Now we wait for the touch information, that is coming from the DeSer side.
5. After that we connect the video source which is a Laptop in our case using an HDMI cable.

Below are the EDID bytes that we are using for the 1920x1200 resolution touch display.

 Modified EDID.dat

Challenges:

1. When the Laptop is connected, the HPD pin on the Ser does not get high and a black screen is shown on the touch display.
2. In case, when we keep the Laptop connected before the power-up of Serializer EVK, then HPD sometimes gets high but still on display, the distorted screen is displayed, and the Laptop is unable to get the right EDID bytes. After that when we disconnect the Laptop to the Ser and then again connect it the screen is displayed on the screen accurately.

Now, we have to make sure that whether the Laptop is connected to the Serializer or not in the power-up, we need that there should not be any distorted screen on the touch screen.

Thanks,

Vikas

Hi Vikas,

Thank you for the update. What is the state of the RX_5V during the scenarios where a black screen is showing on the display? If the Ser is not receiving 5V from the laptop, that might be an issue with the HDMI cable. If the Ser is seeing a consistent 5V from the laptop, are you able to force the hot plug using the ALP tool? Please let me know. 

Sincerely,

Ryan

Hello Ryan,

When we connect the HDMI cable to the laptop, the RX_5V is at 5V but the HPD pin is low during the blank screen. 

Yes, we are able to assert the Hot Plug using the ALP tool when Ser is connected to the laptop.

Can you tell us the startup sequence for Ser and Deser communication? Should we wait for the Ser and Deser locking and after that we should read or write any command to the Ser or not? And which registers show the values that Ser and Deser are locked or not?

Hi Vikas,

When you asserted the hot plug using ALP, did the video output properly on the display?

Section 9 of both the 948 and 949 datasheets spells out the full startup sequences. I have included the written procedures below but the datasheets include additional diagrams and tables to help illustrate the procedures. Register 0x1C of the 948 will indicate lock. 

949 Startup

948 Startup

Please let me know if you have any questions regarding these procedures.

Sincerely,

Ryan

Hello Ryan, 

Thanks for the information. I have considered your answers and tried to implement the same.

Here are my some queries after this: 

1. The scenario in my case is that a display device (a touchscreen) is connected to the Deser (948) through a medium and then the Deser is connected to our Ser (949) using LVDS cable. The thing that is happening here is that we have only access to the Ser device in the whole setup and we are accessing the Ser using either the ALP tool or using MCU through the I2C pins of the Ser. So, when the setup is powered up, the whole system is powered up, i.e. Deser, Ser, and the display device. We have cut out the display source for now which will be connected to the Ser device using the HDMI cable. So, the system is powered up now and now using the ALP tool we can see that the Ser and Deser are having communication (shown in ALP tool:- Linked to Deserializer: Yes). Does it mean that Deser and Ser are locked or not? Because the display screen is still blank because we haven't connected any display source to the Ser using an HDMI cable. Is there any address present in Ser device through which we can check that Ser and Deser are locked?  
2. When should we start reading the Ser device using I2C pins of the MCU so that there should be no glitch in I2C bus lines because I2C signals are also going through LVDS?
3. The startup sequence mentioned for 948, actually we don't have any hand to control that, we can just control the Ser device startup sequence that that is too when the Ser device is powered up and ready for I2C communication through MCU? So, will it affect the performance of the Ser device if we do like this?

Waiting for your answers.

Thank you.

Regards,
Vikas

Hi Vikas,

Thank you for the additional information. Please see my comments below:

Vikas Dubey said:

So, the system is powered up now and now using the ALP tool we can see that the Ser and Deser are having communication (shown in ALP tool:- Linked to Deserializer: Yes). Does it mean that Deser and Ser are locked or not? Because the display screen is still blank because we haven't connected any display source to the Ser using an HDMI cable. Is there any address present in Ser device through which we can check that Ser and Deser are locked?  

The terminology here can be a bit unclear so let me clarify what is happening with link vs. lock. When the Ser and Des are powered on and connected and able to communicate they have "link." This means you can access the registers of the Des through the Ser. You can read register 0x00 of the 948 and if it reads the expected I2C address of the 948 you know that you have link and the two devices are communicating. Once the devices are communicating, sending video data across the FDP-Link will cause "lock." Lock just means that there is "link" and video data is being sent. Register 0x1C of the 948 will indicate lock in bit 0.

Vikas Dubey said:

2. When should we start reading the Ser device using I2C pins of the MCU so that there should be no glitch in I2C bus lines because I2C signals are also going through LVDS?

Here is the power-on sequence diagram and table for the 949 with the I2C ready time highlighted.

Vikas Dubey said:

3. The startup sequence mentioned for 948, actually we don't have any hand to control that, we can just control the Ser device startup sequence that that is too when the Ser device is powered up and ready for I2C communication through MCU? So, will it affect the performance of the Ser device if we do like this?

Ryan Fleetham said:

If the Des is powered on before the Ser has started sending valid video data, you need to perform a reset on the Des. This can be done in software or through PDB.

Sincerely,

Ryan

Hello Ryan.

Thanks for your information. We are trying to follow the same procedures that you have mentioned in the above steps.

We have some doubts regarding the writing of EDID data into the internal SRAM of Serializer, we are following the below procedures to write data into SRAM using our MCU:

MODE_SEL0 = #1, MODE_SEL1 = #5, IDx = #1

1. First we De-assert the hot plug using the registers. (It's working fine). After that, we write the EDID Data using the registers, APB Control Registers (0x48, 0x0D), EDID Low Byte and Upper Bytes (0x49, 0xA0), (0x4A, 0x00), (0x51, 0xA0) and then we are writing the data using APB Write register (0x4B) and incrementing the address after writing 1-byte information. After that, we performed the read operation for SRAM EDID data and we read the first 10 bytes of data correctly. After that, we assert the HDP after 1s delay. After that, we performed the Power-Up Sequence procedure that you have mentioned above.

When we check on the laptop, we found that the EDID received by the laptop is not the same that we wrote on the SRAM, the laptop is receiving the default EDID Data bytes present in the SRAM of the Serializer.

2. But another point is that when we use ALP to do the same above procedure then it works fine on the Laptop. While using the ALP tool, in the HDMI section, we changed the "EDID Mode" to "Internal SRAM" from "External", after that, we modified the below registers using Script:

board.WriteI2C(0x18, 0x48, 0x0D)
board.WriteI2C(0x18, 0x49, 0xA0)
board.WriteI2C(0x18, 0x4A, 0x00)
board.WriteI2C(0x18, 0x51, 0xA0)
data = [0, 255, 255, 255, 255, 255, 255, 0, 4, 33, 0, 0, 0, 0, 0, 0, 1, 0, 1, 3, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0,
1, 0, 1, 0, 1, 0, 1, 0, 15, 60, 128, 160, 112, 176, 35, 64, 48, 32, 54,
0, 64, 104, 33, 0, 0, 24, 0, 0, 0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 79, 4, 6, 42, 128, 130,
8, 71, 18, 254, 10, 6, 3, 0, 0, 204, 6, 24, 0, 32, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 80]
board.EDID_Write(0x00, data, 256)

And then Assert the hot plug-in HDMI section of ALP tool and things are working fine after that.

3. In case using the ALP tool, we do not set the set Internal SRAM in the HDMI window and perform the steps in point 2, and the laptop still detects the default SRAM EDID data bytes.

The question is why do we need to set internal SRAM in the HDMI window when already MODE_SEL0 and MODE_SEL1 are set for internal SRAM??


Thanks.

Regards,
Vikas

Vikas,

It sounds like the MODE strapping on your board is actually not strapping what you expect. Are you using the EVM here? Can you send us a picture of the strap settings? 

I would suggest to use the 949 with internal bridge control mode (EXT_CTL = 0), so MODE_SEL1 should be set to #1

Can you make that change and send us both a picture of the EVM board switches or a register dump of the SER?

Best Regards,

Casey 

Hello Casey,

Thanks for the information.

Yes, we are using the DS90UB949-Q1EVM kit.

The thing is, I am interfacing Serializer using an MCU that is connected to it via the I2C bus. I have tried the below methods that I mentioned earlier also

Vikas Dubey said:

MODE_SEL0 = #1, MODE_SEL1 = #5, IDx = #1

1. First we De-assert the hot plug using the registers. (It's working fine). After that, we write the EDID Data using the registers, APB Control Registers (0x48, 0x0D), EDID Low Byte and Upper Bytes (0x49, 0xA0), (0x4A, 0x00), (0x51, 0xA0) and then we are writing the data using APB Write register (0x4B) and incrementing the address after writing 1-byte information. After that, we performed the read operation for SRAM EDID data and we read the first 10 bytes of data correctly. After that, we assert the HDP after 1s delay. After that, we performed the Power-Up Sequence procedure that you have mentioned above.

When we check on the laptop, we found that the EDID received by the laptop is not the same that we wrote on the SRAM, the laptop is receiving the default EDID Data bytes present in the SRAM of the Serializer.

2. But another point is that when we use ALP to do the same above procedure then it works fine on the Laptop. While using the ALP tool, in the HDMI section, we changed the "EDID Mode" to "Internal SRAM" from "External", after that, we modified the below registers using Script:

board.WriteI2C(0x18, 0x48, 0x0D)
board.WriteI2C(0x18, 0x49, 0xA0)
board.WriteI2C(0x18, 0x4A, 0x00)
board.WriteI2C(0x18, 0x51, 0xA0)
data = [0, 255, 255, 255, 255, 255, 255, 0, 4, 33, 0, 0, 0, 0, 0, 0, 1, 0, 1, 3, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0,
1, 0, 1, 0, 1, 0, 1, 0, 15, 60, 128, 160, 112, 176, 35, 64, 48, 32, 54,
0, 64, 104, 33, 0, 0, 24, 0, 0, 0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 79, 4, 6, 42, 128, 130,
8, 71, 18, 254, 10, 6, 3, 0, 0, 204, 6, 24, 0, 32, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 80]
board.EDID_Write(0x00, data, 256)

And then Assert the hot plug-in HDMI section of ALP tool and things are working fine after that.

and this is working fine with the ALP tool. The problem is with the MCU interfacing. We are trying the same method using the MCU, writing and reading the I2C registers of the Serializers, and we are reading and writing in the same way that I have described in my quoted message.

I am trying to de-assert and assert the HPD pin that's why I am using MODE_SEL as #5 for external bridge control.

Using MCU, I am de-asserting the HPD pin, writing EDID data using APB registers, cross-checking the written EDID data bytes by reading the SRAM data using APB registers and after that, I assert the HPD pin, and I can see that LED D2 is glowed after asserting the HPD pin on EVK kit. But after that, no data is transferred from video source to video display. 

After asserting the HPD pin, we are following the Power-Up initialization that Ryan has suggested for Serializer, but to do the Initialization sequence B we have to wait for the TMDS clock to stable, but the TMDS clock does not get stable and we wait for that for always.

But if we skip the Power-up initialization also, still we are not getting the video source on the video display. After asserting the HPD pin, no display is there.

Can you please help us to fix this issue? Is the ALP tool doing something in between writing commands that we are skipping or what? Please suggest.

Thank you.

Regards,
Vikas.

Hi Vikas,

Would you please clarify the following points?

Vikas Dubey said:

After that, we assert the HDP after 1s delay. After that, we performed the Power-Up Sequence procedure that you have mentioned above.

What do you mean by performing the Power-Up Sequence procedure? Are you turning off both the serializer and desrializer and powering them back on again or are you just powering on the deserializer at this stage?

Vikas Dubey said:

When we check on the laptop, we found that the EDID received by the laptop is not the same that we wrote on the SRAM, the laptop is receiving the default EDID Data bytes present in the SRAM of the Serializer.

If you read the EDID SRAM data on the 949 at this point, do the values match what the laptop received or what you wrote earlier?

Vikas Dubey said:

But another point is that when we use ALP to do the same above procedure then it works fine on the Laptop.

When you say it works fine, does this mean the laptop received the EDID data you expected?

Vikas Dubey said:

While using the ALP tool, in the HDMI section, we changed the "EDID Mode" to "Internal SRAM" from "External", after that, we modified the below registers using Script:

You said that you used ALP for the same process you are trying with the MCU but here you said that you are also changing a setting in the ALP HDMI GUI. Are these two separate tests or are you always changing a setting in the ALP HDMII GUI when using ALP?

Vikas Dubey said:

I am trying to de-assert and assert the HPD pin that's why I am using MODE_SEL as #5 for external bridge control.

Are you able to try using MODE_SEL1 as #1 as Casey suggested and providing a register dump? 

Thank you,

Ryan

Hello Ryan,

Ryan Fleetham said:

What do you mean by performing the Power-Up Sequence procedure? Are you turning off both the serializer and desrializer and powering them back on again or are you just powering on the deserializer at this stage?

As I had already mentioned earlier, once I powered up the whole system, it means that Serializer, Deserializer, and Touch Screen device, all 3 devices are powered up in one go. After that, completing all the EDID data byte write and assert the HPD pin, I am performing the Power Up sequence as mentioned in the datasheet of Serializer as follows:



but while doing this sequence, after completing Sequence A, when I wait for the TMDS clock to stable, I am waiting forever as register 0x0C[2] is never 1.

Ryan Fleetham said:

If you read the EDID SRAM data on the 949 at this point, do the values match what the laptop received or what you wrote earlier?

No, the data bytes are not the same, the default data bytes are present, below as present in the datasheet of Serializer.

Ryan Fleetham said:

When you say it works fine, does this mean the laptop received the EDID data you expected?

Yes, using the ALP tool, the written data bytes are exact that is received by the Laptop. On the other hand, sometimes, the Laptop is not receiving any EDID data bytes when writing data using MCU.

Ryan Fleetham said:

You said that you used ALP for the same process you are trying with the MCU but here you said that you are also changing a setting in the ALP HDMI GUI. Are these two separate tests or are you always changing a setting in the ALP HDMII GUI when using ALP?

These are the same tests. As already told you, MODE_SEL0 is set to #1, so it is set to Internal SRAM for EDID data bytes, but when I open the ALP tool, it doesn't detect this setting from the EVK strap, it detects the EDID Data Bytes from "External". I don't know what is the reason, so I manually change the setting to the Internal SRAM.

Ryan Fleetham said:

Are you able to try using MODE_SEL1 as #1 as Casey suggested and providing a register dump? 

No, this doesn't help also.

Thanks.

Regards,
Vikas

Hi Vikas,

Thank you for the clarifications. 

Vikas Dubey said:

These are the same tests. As already told you, MODE_SEL0 is set to #1, so it is set to Internal SRAM for EDID data bytes, but when I open the ALP tool, it doesn't detect this setting from the EVK strap, it detects the EDID Data Bytes from "External". I don't know what is the reason, so I manually change the setting to the Internal SRAM.

This makes it seem like the 949 isn't loading the strap settings correctly. Would you please try pressing and releasing the PDB on the 949 after it turns on to see if you can get ALP to recognize the correct strap setting without having to manually set the EDID source? If for some reason the 949 isn't set for the internal SRAM EDID, this could explain why the laptop doesn't even receive EDID data at times.

Vikas Dubey said:

No, the data bytes are not the same, the default data bytes are present, below as present in the datasheet of Serializer.

I'm still a little unclear about this. I understand the the laptop receives the default EDID data spelled out in the datasheet and that the 949 has the correct EDID when you read it back after loading the SRAM EDID. Does the 949 keep the correct EDID settings after following the power-on procedure or does it revert back to the default 949 EDID data spelled out in the datasheet?

Thank you,

Ryan

Hello Ryan,

Let me clear some points.

Ryan Fleetham said:

This makes it seem like the 949 isn't loading the strap settings correctly. Would you please try pressing and releasing the PDB on the 949 after it turns on to see if you can get ALP to recognize the correct strap setting without having to manually set the EDID source? If for some reason the 949 isn't set for the internal SRAM EDID, this could explain why the laptop doesn't even receive EDID data at times.

Yes, I have tried pressing the PDB button and releasing it after that, and yes, after that it loads/reads correct strap settings but after this also, the laptop is not receiving any EDID data bytes when Serializer is interfaced using MCU.

Let me clear you one more thing there are two tests that I shared with you. One is that I am using the ALP tool to program the Serializer and write EDID data bytes to the Internal SRAM of the Serializer, and using this method, it works fine every time. But, in my other thread, where I mentioned that this method also does not work with some laptops. No EDID data bytes are received by the laptop. So, this is another issue, we can resolve it later because interfacing of Serializer with MCU is our main priority right now. And another test is the interfacing of Serializer using MCU, where this issue is happening, so please get clear that right now, we are talking about MCU interfacing. 

Again I am repeating what I am doing to transfer the video signal to the display device using MCU. Here are the steps,
1. Power ON the system (Serializer, Deser, and Touch Screen Device and Laptop). The HDMI cable is already connected to the laptop and the Serializer. RX_5 LED on the Serializer is already lit up. Strap settings are as, MODE_SEL0: #1, MODE_SEL1: #5.
2. Wait for local I2C Ready time (2ms), after that start reading and writing I2C local registers of the Serializer. 
3. Dessert the HPD pin, enable the APB interface to write the EDID data bytes to the internal SRAM of the Serializer.
4. Write EDID data bytes and then again Read EDID Data Bytes from SRAM of Serializer. All 256 bytes are matched to what I have written.
5. Now, Assert the HPD pin, HPD LED lit up on the EVK kit.

But, no video transfer to the Display device.

I have tried with MODE_SEL1: #1 strap setting also, where internal bridge setting is enabled, but using this method also, it doesn't work.

Please help with this.

Ryan Fleetham said:

I'm still a little unclear about this. I understand the the laptop receives the default EDID data spelled out in the datasheet and that the 949 has the correct EDID when you read it back after loading the SRAM EDID. Does the 949 keep the correct EDID settings after following the power-on procedure or does it revert back to the default 949 EDID data spelled out in the datasheet?

Yes, after writing the EDID data bytes, I read it again from the SRAM and I found that it has the correct EDID data bytes. I have told you that during the Power-Up Sequence, when I do the Initialization Sequence B, where I have to wait for the TMDS clock to be stable, I wait for there for infinite because no TMDS clock is there to the Serializer.

I can do one thing after doing Initialization Sequence A in Power-Up Procedure, I will check if the correct EDID data bytes are there or not.

Other than this, can you please let me know registers that I have to enable before doing these settings, like Deaaserting, Asserting, and Writing EDID data bytes. Somewhere I think we are missing registers to write or read in Serializer.

Can you please let me correct if I am following the right procedure that I am doing or not? Do I have to enable or disable some more registers in Serializer that's why it is not able to perform correctly, because the ALP tool is able to do the same procedure correctly while using MCU, but it is not?

Please, let me know the registers through which I am asserting, de-asserting, and writing the EDID data bytes, might be, that I am configuring the wrong register to do the above steps. 

Thank you.

Regards,
Vikas

Hi Vikas,

Thank you very much for the clarifications - they were very helpful!

The process should be the same between ALP and writing with an MCU (that is, ALP shouldn't be automatically configuring the 949) so I don't think we are missing any registers. 

Would you please send me all of the I2C commands you send the 949 from the MCU? 

Would you please try the following two tests with the system? I just want to make sure the fundamentals are fully functional. 

Test 1: 

Strap MODE_SEL0 to 1 and MODE_SEL1 to 1. Without ALP connected, power on the system and see if the connected laptop has detected the 949 as a display. If it has not, toggle the PDB (949), wait a few seconds, and check again.

Test 2:

Strap MODE_SEL0 to 1 and MODE_SEL1 to 5. Without ALP connected and with the MCU connected, power on the system. Toggle the PDB (949) and wait a few seconds. Force the hot plug with the MCU and see if the connected laptop has detected the 949 as a display. 

Sincerely,

Ryan

Hello Ryan,

Thank you for your suggestions.

Actually, I did "Test 2", and it worked. But the point is, now I have been able to find the issue and it's working now, actually what I have done is that I have changed the APB_ADR0 to 0x00 and removed the setting of EDID_ID register of Serializer and now I have been able to transfer the data over Serializer.

Thanks for your help. 

Actually, I have asked another question related to EDID data transfer with different laptops on the E2E forum. That issue is still there, I am attached the EDID data bytes that I am writing into the SRAM of the serializer. Can you please check that do these EDID data bytes support most of the laptops to send the video data or not? I have another question is that is there any Universal EDID data bytes through which this Serializer can support as well as our Display device also. Our display screen is having 1920x1200 display resolution.

In the above posts, I had asked you other points also that sometimes, the SDA line is low while interfacing the Serializer over I2C, and sometimes, the SDA or SCL lines do get distorted, so what can be the issue behind this? This thing is totally frustrating as sometimes, we are able to communicate properly with Serializer over I2C and sometimes, it isn't able to respond as either the SDA pin is low or any of the I2C signals are distorted. As, the EVK kit is already having a 4.4k resistor pull-up with the I2C bus, so we are not pulling up the I2C bus from our I2C master MCU, and we are running the I2C bus at a 400kHz clock rate. Please help us with this issue.

Thank you.

Regards,
Vikas

Hi Vikas,

Fantastic - I'm glad to hear you were able to make some progress!

I tried loading your EDID onto a similar setup in the lab and was unable to recognize the 949 as a display. If you can share all of your video specifications (pixel clock, active pixels, blanking, sync width, front porch, image size, border, etc. for both vertical and horizontal pixels) I can generate a new EDID to see if that makes a difference.

With regards to the SDA and SCL lines, the connection can be inconsistent when using jumpers to connect to the headers on the EVM. The jumpers introduce additional noise, impedance, capacitance, and even inductance that can hinder the I2C communication. I recommend using the smallest jumpers you can for the SDA, SCL, and GND lines to minimize these effects.

Sincerely,

Ryan

Hello Ryan,

Thank you for your help.

Actually, I did the same but didn't get the result. I had shortened the connecting wires but the issue still pertains. 

Another point that I need to share with you is that the microcontroller that I am using to interface the Serializer using I2C doesn't support Multi-Master. So, is there any dependency that if Multi-Master is not supported then it can work properly with the Serializer?

What I want to discuss is whether there is any method using which I can eliminate the TI microcontroller to interface the I2C bus with the Serializer, so that I can't use the ALP tool and there will be a single master that is our MCU that will interface the Serializer. 

Regarding the Jumper J37 which is shorted with V3.3 so that I2C_VCC is pulled up with 3.3V, what if removed the pull-up by removing the J37 jumper and providing the pull-up resistor from the MCU end or the providing externally. Is this possible to resolve the issue?

The problem is happening that, whenever the I2C master (MCU) writes to the Serializer, then after one successful writing to the Serializer, the SDA pin is asserted to 'Low' and never pulled up again to 'High'.

I2C speed is set to 400kbps and an analog filter is set at the MCU end to reduce the noise. 

Please share your thoughts.

Thanks.

Regards,
Vikas

Hi Vikas,

Vikas Dubey said:

Another point that I need to share with you is that the microcontroller that I am using to interface the Serializer using I2C doesn't support Multi-Master. So, is there any dependency that if Multi-Master is not supported then it can work properly with the Serializer?

This should not be an issue. When ALP is not connected, the TI MCU will not send I2C commands meaning your connected MCU should not run into multi-master or arbitration issues.

Vikas Dubey said:

Regarding the Jumper J37 which is shorted with V3.3 so that I2C_VCC is pulled up with 3.3V, what if removed the pull-up by removing the J37 jumper and providing the pull-up resistor from the MCU end or the providing externally. Is this possible to resolve the issue?

Removing Jumper 37 would allow you to use a different pull-up on the side of your MCU. It is possible that the total capacitance of the I2C bus exceeds what is allowable with the default pull-ups. Please see this app note (https://training.ti.com/calculating-correct-pull-resistor-value-i2c-bus-applications) to calculate what pull-up resistor is recommend given the connected devices/capacitors. If the rise/fall times are out of specification, the 949 may not be properly reading the commands sent from your MCU. 

Vikas Dubey said:

The problem is happening that, whenever the I2C master (MCU) writes to the Serializer, then after one successful writing to the Serializer, the SDA pin is asserted to 'Low' and never pulled up again to 'High'.

Would you please share a scope capture of this behavior? Does this happen every time or does it work as intended sometimes? 

Regarding your MCU, are you able to have successful I2C communication with devices besides the 949? What happens if your MCU does not receive an acknowledgement (you can test this by trying to communicate with a device address not present on the I2C bus)? 

Sincerely,

Ryan

Hello Ryan,

Thank you for your reply. 

Actually, I solved the problem without removing the Jumper J37 which is pulling up the I2C bus to 3.3V.

The problem was that the clock line which is derived by our MCU which is the I2C master was not generating enough slope to the clock and data lines of the I2C bus during rising and falling edges, i.e., the slew rate of the I2C bus lines was very high so I reduced the slew rate and now it's working and I am able to communicate properly with the Serializer.

Now, I new problem has arrived that, after communicating with the Touch Controller device which is connected to the other side of Deser, after some time, the I2C bus crashes, and the SCL line is distorted as below.



After that, I am unable to restore the I2C bus, i.e., the SCL line, so I have to restart the Serializer and the MCU setup.

Now, coming back to the setup. A touch controller device is connected to the Deser 948UB and then Deser is connected to the Ser 949UB through the LVDS link. At the Ser end, our MCU is acting as an I2C master, which wants the Touch Controller data from the Deser side.

I am able to get the Touch Controller data but after some time, as stated above SCL line is distorted. Can you please share with me the cause of this issue and how can I solve this to get the proper communication over the FPD link.

The touch controller is having baud rate of 400kbps and I am also running the MCU as an I2C master with a 400kbps data rate. I have enabled the I2C passthrough in the 0x03 register address and set the Touch Controller device address in the 0x06 and 0x07 register addresses of Serializer. 

I have to read the data from the touch controller at every15ms and I am querying the Serializer through the I2C bus every 10ms to miss out on any data. 

Is there anything I have to wait for the Serializer to be stable or is there any limit to access the I2C bus at this rate? Please share your thoughts and solve this issue.

Thanks.

Regards,
Vikas

Hi Vikas,

Glad you could get I2C functioning locally on the serializer!

Vikas Dubey said:

Now, I new problem has arrived that, after communicating with the Touch Controller device which is connected to the other side of Deser, after some time, the I2C bus crashes, and the SCL line is distorted as below.

A couple of questions on this:

• To clarify, is the attached screenshot of the deserializer or serializer side? 
• Would you please include a scope capture of both the other side when the I2C bus crashes as well as what the deserializer I2C bus looks like when I2C is functioning?

Vikas Dubey said:

The touch controller is having baud rate of 400kbps and I am also running the MCU as an I2C master with a 400kbps data rate. I have enabled the I2C passthrough in the 0x03 register address and set the Touch Controller device address in the 0x06 and 0x07 register addresses of Serializer. 

Register 0x06 should contain the deserializer address.

Registers 0x07 and 0x08 should have the address and alias address of the Touch Controller respectively.

Vikas Dubey said:

Is there anything I have to wait for the Serializer to be stable or is there any limit to access the I2C bus at this rate? Please share your thoughts and solve this issue.

When using remote I2C, the master device (in this case, your MCU on the serializer side), needs to support clock stretching to give the remote Touch Control time to respond across the FPD-Link. Here is an app note that goes into the specifics of clock stretching (I2C Communication Over FPD-Link III with Bidirectional Control Channel (Rev. A)). Does your MCU support clock stretching? 

Sincerely,

Ryan

Hello Ryan,

Here are my points related to your above points.

Ryan Fleetham said:

A couple of questions on this:

• To clarify, is the attached screenshot of the deserializer or serializer side? 
• Would you please include a scope capture of both the other side when the I2C bus crashes as well as what the deserializer I2C bus looks like when I2C is functioning?

1. The attached image is from the Serializer side.
2. Actually the issue is that the Deserializer side connection is a bit congested as the Touch Controller and Deser are embedded on a single PCB and it really very difficult to probe the signals to the I2C bus on the Deser side. But, I will try my hard to get into Deser's side to find the cause of the problem. When I will able to get into Deser side connections when will update you about this.

Ryan Fleetham said:

When using remote I2C, the master device (in this case, your MCU on the serializer side), needs to support clock stretching to give the remote Touch Control time to respond across the FPD-Link. Here is an app note that goes into the specifics of clock stretching (I2C Communication Over FPD-Link III with Bidirectional Control Channel (Rev. A)). Does your MCU support clock stretching? 

Yes, our MCU supports the clock stretching and I have the shared application note earlier also but I wasn't able to find the solution to the problem. But to cross-check the information, I will recheck whether my MCU supports clock stretching or not. 

Meanwhile, can you please let me know any other things, that are causing this problem this is really frustrating to deal with because I haven't had any case in the past where the I2C bus is distorted like this? Is it happening due to Touch Controller, which is not able to respond to the MCU I2C queries?

As per my understanding, how Touch Controller data is coming to MCU over I2C is that:
MCU queries for the registered address to the device address present in Slave ID and Slave Alias of Serializer, as the Pass-through is enabled, the Serializer now acts as the proxy master and the Serializer queries to the Slave ID address into the Deser side and Deser now queries the Touch Controller and then the Touch Data is sent to the back channel to the Serializer and then the information is retrieved to the MCU. Please correct me wherever I am wrong. 

If this is the case the Serializer is the culprit for the distorted line of the I2C bus or not? Please help me.

Thanks.

Regards,
Vikas

Hi Vikas,

Thank you for looking into the deserializer side. 

Vikas Dubey said:

Meanwhile, can you please let me know any other things, that are causing this problem this is really frustrating to deal with because I haven't had any case in the past where the I2C bus is distorted like this? Is it happening due to Touch Controller, which is not able to respond to the MCU I2C queries?

Just to clarify, does this distortion on the I2C bus only happens after the bus crashes or is this always present when trying to use the Touch Controller via remote I2C? What is the status of the SDA line when this crash occurs and are you able to get successful communication with the Touch Controller before the crash? 

A couple of thoughts as to what could be causing this distortion:

• Poor ground connection between the I2C devices on the serializer side.
• Too much capacitance/incorrect pull-up value on the I2C bus. Two thoughts on this:
  • Are the 4.7k resistors that come on the EVM the only pull-ups on the I2C lines (i.e. no pull-ups on the MCU side)? 
  • I think you mentioned an analog filter on the I2C bus. What does this look like and does this add capacitance to the line? 

Vikas Dubey said:

As per my understanding, how Touch Controller data is coming to MCU over I2C is that:
MCU queries for the registered address to the device address present in Slave ID and Slave Alias of Serializer, as the Pass-through is enabled, the Serializer now acts as the proxy master and the Serializer queries to the Slave ID address into the Deser side and Deser now queries the Touch Controller and then the Touch Data is sent to the back channel to the Serializer and then the information is retrieved to the MCU. Please correct me wherever I am wrong. 

I think your understanding is correct but I just want to make sure the process is clear:

1. With passthrough enabled, the MCU writes to the bus the address stored in the target alias register of the serializer and indicates write/read. 
2. The serializer holds SCL low and sends the I2C data through the FPD-Link to the deserializer.
3. The deserializer, acting as the master on its local I2C bus, writes to the address stored in the target ID register of the serializer and indicates write/read.
4. The slave device on the deserializer I2C bus (Touch control), acknowledges to the deserializer.
5. The deserializer sends the acknowledgement through the back channel FDP-Link to the serializer.
6. The serializer releases SCL and communicates the acknowledgement to the MCU. 

Vikas Dubey said:

If this is the case the Serializer is the culprit for the distorted line of the I2C bus or not? Please help me.

The serializer should only be responsible for holding SCL low until communication happens on the deserializer I2C bus. This would explain seeing 0V on SCL but not the distortion you are seeing.

Sincerely,

Ryan

Hello Ryan,

Thank you for your help.

Here are my quotes related to your comments.

Ryan Fleetham said:

Just to clarify, does this distortion on the I2C bus only happens after the bus crashes or is this always present when trying to use the Touch Controller via remote I2C? What is the status of the SDA line when this crash occurs and are you able to get successful communication with the Touch Controller before the crash? 

Yes, before that it works fine and after some time, clearing the touch to interrupt using 0xC7 register read of Serializer, the I2C bus hangs and the SDL pin is kept low.

I did some research about the troubleshooting of the I2C comm, and found out that, sometimes, when the I2C slave device doesn't get proper SCL clock lines so it waits for valid clock pules to respond to the master message, so till the arrival of valid clock pulses, it (I2C slave device) keeps the SDA line low? Is it the same case happening with the Serializer device too? 

I did some research that, if the I2C master device sends 16 or 8 clock pulses on the SCL line then the Slave device releases the SDA line. I tried this method also, didn't work. I tried making the SCL pin as output gpio and toggling the state of gpio pin for 16 and 8 times, to give clock pulses, but this also didn't work.

Ryan Fleetham said:

• Are the 4.7k resistors that come on the EVM the only pull-ups on the I2C lines (i.e. no pull-ups on the MCU side)? 
• I think you mentioned an analog filter on the I2C bus. What does this look like and does this add capacitance to the line? 

Yes, no pull-ups from the MCU side, the pull-ups that are on the EVK side, which are pulled up to 3.3V using 4.7k ohm resistors, are the only pull-ups in the I2C bus. Regarding that also, can you please let me know why C87 and C88 capacitors are used with the I2C bus lines. Generally, I haven't seen any capacitors on the I2C bus? Is it necessary? Can we remove the capacitors present on the EVK?

I don't know about this analog filter as this is related to the internal working of the MCU I2C bus. I will gain more knowledge about the capacitance add-on due to this analog filter.

Ryan Fleetham said:

The serializer should only be responsible for holding SCL low until communication happens on the deserializer I2C bus. This would explain seeing 0V on SCL but not the distortion you are seeing.

Sometimes, this is distorted and sometimes the SDA line is low. Is there any periodic timing that we have to follow? Because I tried the same method to read the registers from the touch controller using the ALP tool but in this case, no I2C bus was hung. I am surprised that why it doesn't get hung. Is it because the ALP tool sends some periodic message to the Serializer?

Please help me with this issue, as it is taking too much time to solve and the production with this Serializer is getting a bit difficult.

Other than this query, I have another query related to the EDID data bytes. I thought, other than creating a new thread for this latest query, I can ask the thing in this thread only, as it was my early problem also.

My problem is that I want to use an external EEPROM, which will be attached to the Serializer EVK, and I want to write EDID data bytes to this EEPROM using my MCU. As I had told you earlier that I have been able to write the EDID data bytes to their Serializer Internal SRAM using the APB interface, but now I want to write the EDID data bytes to the EEPROM attached to the Serializer EVK. Is there any method using which I can write the EDID data bytes o the EEPROM of the EVK, please let me know?

Thanks.

Regards,
Vikas

Hi Vikas,

Vikas Dubey said:

Yes, before that it works fine and after some time, clearing the touch to interrupt using 0xC7 register read of Serializer, the I2C bus hangs and the SDL pin is kept low.

A few of questions here:

• Would you please provide a scope capture of the I2C protocol working fine? I want to make sure the communication looks as expected.
• I'm a bit confused about what exactly is happening here. Is the I2C bus hanging only when you try to read 0xC7 or are you repeatedly reading 0xC7 and it crashes randomly?
• Are you referring to the SCL or SDA pin here? 

Vikas Dubey said:

I did some research about the troubleshooting of the I2C comm, and found out that, sometimes, when the I2C slave device doesn't get proper SCL clock lines so it waits for valid clock pules to respond to the master message, so till the arrival of valid clock pulses, it (I2C slave device) keeps the SDA line low? Is it the same case happening with the Serializer device too? 

The 949 should release the SDA line on its own. Additionally, if the 949 detects that the SDA line is held down for too long, it will attempt to clear the bus by sending 9 clocks on SCL. These settings can be found in register 0x05 and it looks like you have them enabled already. 

I've seen it before where an MCU will pull the SDA line low if it doesn't receive an acknowledgement. Would you please try using the MCU to try to communicate with a device address not present on the bus? For example, if no device has address 0x50, try writing 0x50 to the bus. Ideally, you should see no response and a timeout after which both SCL and SDA are pulled high.

Vikas Dubey said:

Regarding that also, can you please let me know why C87 and C88 capacitors are used with the I2C bus lines. Generally, I haven't seen any capacitors on the I2C bus? Is it necessary? Can we remove the capacitors present on the EVK?

These two capacitors are to adjust the rising edge time on the I2C bus. Provided that the rise/fall times are within spec for all devices on the bus, these are not necessary and you can try without them.

Vikas Dubey said:

Sometimes, this is distorted and sometimes the SDA line is low. Is there any periodic timing that we have to follow? Because I tried the same method to read the registers from the touch controller using the ALP tool but in this case, no I2C bus was hung. I am surprised that why it doesn't get hung. Is it because the ALP tool sends some periodic message to the Serializer?

No, there is not a periodic timing you need to follow. You are correct that the ALP tool sends periodic messages but this is only to keep the GUI up to date and not to keep the communication working with the 949. 

I'd like to understand more about these two test (i.e. MCU writing and ALP writing). Are you just doing a single read in both cases or are there differences (e.g. sending more communications with one method, reading more than just one register, etc.)?

Would you please send a scope capture for both methods? I'd like to see if there are any differences.

Vikas Dubey said:

My problem is that I want to use an external EEPROM, which will be attached to the Serializer EVK, and I want to write EDID data bytes to this EEPROM using my MCU. As I had told you earlier that I have been able to write the EDID data bytes to their Serializer Internal SRAM using the APB interface, but now I want to write the EDID data bytes to the EEPROM attached to the Serializer EVK. Is there any method using which I can write the EDID data bytes o the EEPROM of the EVK, please let me know?

Just to make sure I understand what you are asking, do you want to have a blank EEPROM connected to the 949 board and then write EDID data to that EEPROM via the MCU? Is this correct? If so I can check to see if there is a method for doing this. 

Sincerely,

Ryan

Hello Ryan,

Thank you for your information.

I will get to back you after some time regarding the I2C issue with the Serializer. 

For now, please let me know how can I write EDID data bytes to the blank EEPROM connected to the 949 Serializer EVK board using programming?

Ryan Fleetham said:

Just to make sure I understand what you are asking, do you want to have a blank EEPROM connected to the 949 board and then write EDID data to that EEPROM via the MCU? Is this correct? If so I can check to see if there is a method for doing this. 

Yes, the EEPROM is blank and I want to write EDID data bytes using the ALP tool or any method (like using MCU to write data to Serializer using I2C bus), etc. Please let me know about this method.

Thanks.

Regards,
Vikas

Hi Vikas,

Thank you for the confirmation. When the EEPROM is directly connected to the 949 EVM, there really isn't a way to write to the EEPROM. What typically works best is to connect the EEPROM to a breadboard or something similar and then connecting a device that can write the EDID to the EEPROM's I2C bus. This could be the MCU, a USB2ANY, or even the EVM through its I2C header. Using the EVM for this operation would allow you to use ALP for the writing of the EDID to the EEPROM.  

Sincerely,

Ryan