• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 33 subscribers
  • Views 522 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DS90UB948-Q1: i2c timing between 948 and front screen MCU

Li Zone
Prodigy 20 points
Part Number: DS90UB948-Q1


Dear Sir

The following figure is the IIC data between ub948 and screen MCU collected by me with logic analyzer.

The next one from the SOC side,between SOC and ub941.

And you can see on the 948 side,there is a gap of about 35us between the sender sending a byte (8 bits) and the receiver sending ACK, which is absent from the SOC side.It is worth noting that there is a time interval for each byte of ACK. As shown in the figure below.

I have encountered a loss of TP coordinate data, which is suspected to be caused by the slow reading of the host. After increasing the i2c rate, this problem has been reduced. We want to optimize the ACK time to see if it can help the problem. So I would like to ask, can this ACK time be shortened?

I hope you can give me some suggestions.

Best Wishes

  • 0
    TI__Mastermind 25765 points

    Hello,

    I will look into this and get back to you in 1-2 days.

    Regards,

    Ben

  • 0 in reply to Ben Dattilo
    TI__Mastermind 25765 points

    Hi,

    The top picture looks like the SER is the controller, and is passing to the DES to read from the remote MCU, is that correct? It seems in this case the MCU is actually stretching the clock between the data bits and the ACK.

    Regards,

    Ben

  • 0 in reply to Ben Dattilo
    Prodigy 20 points

    hi ben,

    Yeah,you are right.The process looks  like this.

    The TP IC sends the touch data to the remote MCU, according to our actual measurement findings, at the rate of TP IC transmission, MT2712 may not be able to read the REG before the data is overwritten.Each byte has such a long stretch, which adds up to time consuming.We want to optimize everything we can to shorten the time.

    This obvious stretching is not normal, is it? Do you mean I need to consult the remote MCU about this phenomenon?

    Best wishes

  • 0 in reply to Li Zone
    TI__Mastermind 25765 points

    Hello,

    Ah okay, thank you for sharing this diagram, it is clear. Yes, I think it would be best to consult with the MCU about this clock stretching, as it does not seem to be coming from the 948 side.

    Regards,

    Ben

  • 0 in reply to Ben Dattilo
    Prodigy 20 points

    Hi Ben,

    Okay, I will consult the MCU later. And then, I want to ask one more question.

    This is from MT2712 and 941,the interval between Bit A and Bit B is about 140us,according to the waveform, the slave machine pulls down the SCL, causing the transmission delay.

    Is this also caused by the remote MCU? Or did the 941 do it in-house? 

    As far as I know, some slave computers, after receiving the data sent by the master, need to do some internal processing, which will slow down the SCL delay for the master to send the next byte. When the slave is ready to receive/send the next byte, it releases the clock and starts the next transmission. However, I don't know whether the slave is 941 or remote MCU in this process.

    Best wishes

  • 0 in reply to Li Zone
    Prodigy 20 points

    Hi Ben,

    I'm very sorry. Please allow me to correct my mistake. It's byte A and byte B, not bit.

    Best wishes

  • 0 in reply to Li Zone
    TI__Mastermind 25765 points

    Hello,

    As you said, this appears to be the I2C target stretching the clock until it is ready to receive the next byte of data. Generally speaking, the I2C target is the device that is receiving the clock, whereas the I2C controller is the device initiating the data transfer. Based on the diagram you showed before it would seem the MCU is acting as a target in this case, and stretching the clock. However, this isn't completely clear to me from the signals you have posted. Can you describe what transaction is taking place here? Is the 941AS reading from the MCU?

    Regards,

    Ben

  • +1 in reply to Ben Dattilo
    TI__Mastermind 25765 points

    Also,

    In case you have not seen these yet, here are two app notes that discuss I2C communication over FPD-Link:

    SNLA131A - I2C Communication Over FPD-Link III with Bidirectional Control Channel

    snla131a.pdf

    SNLA222 - I2C over DS90UB913/4 FPD-Link III with Bidirectional Control Channel

    snla222.pdf

    Regards,

    Ben

  • 0 in reply to Ben Dattilo
    Prodigy 20 points

    Hi ben,

    Thanks for your support ! I think I found a way to optimize it.

    Best wishes

  • 0 in reply to Li Zone
    TI__Mastermind 25765 points

    Of course, I am glad you were able to optimize. I will close this thread.

    Regards,

    Ben