DS90UB948-Q1: Black screen IIC delay

Hi,

Looking at the provided waveform it appears that the bus on the receiving side is being held low, rather than simply a delayed I2C transaction.

Could you please check that there are no link errors or loss of lock during the transaction?

What devices are connected to the I2C bus? And, what are their respective I2C addresses?

Thanks,

Lysny

Hi  Lysny,

      Follow my team member, Jingjing Zhao's  Question, we use logic analyzer to monitor the iic signal both in side of 947 & 948, we really found in some exception, the iic clock/data has be been delayed in the 948 side which is the slave device. However the MCU in slave side don't has clock stretch behavior. It seems that the iic clock&data in slave side(948) has been decode/de-serialized delayed about 7.7ms. 

      We want to know which exception can cause it? also, you can see from our system, the LG TFT connected to 948 via FPC line with LVDS signal used. we are not sure whether the TFT can affect the de-serialize behavior of 948?  

       Wish your support the answers, please, Thanks. Detail refer to below:

In normall scenario, we can see,  iic clock&data has no delay in 948 side if master launch iic write (slave address=0x71;  data =0x04) via 947;  all ACK is OK.

But in exception scenario, we can see the slave address ACK clock & data is right, but the for data 0x04, it's clock and ACK has been delayed  nearly 7.7ms. 

Zoom in below

when iic master in side (947) has not received the ACK from slave(948) in 1.8ms, it shall do NACK operation and stop current transition.

Also, the ACK clock has been delayed nearly 976us offset its data clock. 

Hi  Lysny,

      For our mentioned issue,  0x71 is the configured iic slave address of 948,  and you see in the exception transcation, the LOCK & PDB  of 948 are always high which are normal. Also, the MCU-RL78 connected to 948 has not done clock strecth or held operation. Really, second group iic clock to used to transfer data 0x04 has been delayed, and even its related ACK has been delayed.

Hi, Lysny,

There are more detail description/background from my colleague---Mr. Liu Changyuan. Would you please kindly check and give us your suggestion?

Thanks

Jingjing

Hi,

Could you share what was different about your setup between the normal scenario and the exception scenario? I'm not clear if something was changed about the setup.

Also, is the I2C address of the RL78 target 0x71? The 948 does not support a 7bit I2C address of 0x71 set via strap. Is the device address being changed via register?

In an attempt to isolate the source of the issue, does communicating directly to the RL78 target at the second analyzer location work? 

Thanks,

Lysny

Hi Lysny,

    After double checked, 0x71 is really the slave address of RL78-MCU not the 948 via hardware strap.   The setup for normal & abnoraml scenario are the same, but

only if the exception occured, we can monitor that the second group of iic clock is really delayed from 948. 

    From below figure captured in exception scenario, we can see that for the salve address data 0x71, the slave device RL78-MCU has feedback its ACK and clock. But for the next data 0x04，

the slave device RL78-MCU received the clock delayed about 7.7ms firstly, then its ACK feedback delayed as well.

    So, we  think it's the clock de-serialized by 948 delayed caused this issue, and we confused which exception can cause 948 de-serialized delayed. Wish your minds and feedback, Thanks.

Hi Changyuan,

Okay, I want to look at the registers of the deserializer and serializer when the exception condition is happening. Could you please recreate the delayed I2C condition and then read registers 0x23 and 0x41 in the deserializer and register 0x3 in the serializer?

Thank you,

Lysny

Hi Lysny,

After we added resistance in both line of SCL & SDA from 948 to RL78-MCU, we try to reproduce the issue, then use oscilloscope to monitor the SCL line, we find that it's really the RL78-MCU to stretches the clock and holds its state to low voltage because RL78-MCU is busy handling TFT fault feedback. RL78-MCU needs to store the TFT Error Flag to MCU's internal Data Flash, MCU disabled all interrupt when it did fault storage, so the IIC interrupt is hung up until the Data Flash operation done. We have tested that the maximum time of Data Flash operation is about 9.8ms. That's why the IIC clock is stretched nearly about 4.5ms like below. 

However, Why the 947 & 948 point have not detected the iic clock stretch. especially the IIC master at the side of 947?  Per my understanding, if 947&948 can detect the clock stretch of IIC salve device[RL78-MCU],  IIC master shall not do NACK operation before slave return the ACK.  Any special registers of 947 & 948  or configuration can focus this issue?

Wish your confirm and feedback, Thanks.