Other Parts Discussed in Thread: ALP,
I have two setups here: One is the product were working on, with IMX8->941->cable->948->Touch Panel, and the other is Analog Launch Pad->949EVM->cable->948->Touch Panel. I use the 949EVM setup to validate the LCD Module with 948 and touch panel before involving our IMX controller board. This has been great so far. The issue now is communicating with the Touch Panel over remote I2C. On the 949EVM setup, this all works great. Python commands in the ALP have no problem talking to the Touch Panel. With the IMX and the 941, we have had no problems accessing the 941 or the remote 948 over I2C. But, when we try to communicate with the remote Touch Panel, we see the I2C address on the remote I2C bus, but then we either see all zeros on the data line, appearing to be driven by the 948 (scope images attached) or we see the clock line held low for abut 250ms. Sinding a command as simple as i2cget -y 6 0x5D 0x81, we see the 0x5D on the bus, but then the 0x81 appears as 0x00. On the other hand, i2cdetect -y 6 works fine. I connected two other very simple I2C devices to the remote I2C bus. I2cdetect works, but accessing those parts has the same problem as accessing the goodix touch panel chip. Given that this same LCD unit with 948 and touch panel works on the 949 eval setup, what mechanism could be interfering with i2c? I am setting register 0x17 of the 941 to 0x9E, so I2C_PASS_ALL is on.
Three of the scope shots are the failure, the other is the successful case when using the 949EVM on the serializer end. The LCD module on the receiving end, where the scope is connected, is the same physical unit in both cases.
The core question is, what is interfering with I2C?
