• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 2166 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.

DS90UB913A-Q1: FPD-LINK disconnection during remote I2C communication

Tomoaki Yoshida91
Genius 5255 points
Part Number: DS90UB913A-Q1

Hi team,

We have problems with I2C communication of 913A - 914A.

We are using 914A and 913 A is used for camera.

Each has independent power supply, it is not Power-over system.

There is a device with remote slave I2C addres on 913A side.

We will access I2C from the host MCU on the 914A side to the remote slave device on the 913A side.

When link between 914A and 913A is lost during 913A's local I2C command is being executed, local I2C of 913A will be fixed at SCL: high and SDA: Low.

In fact, the 914A power supply is instantly stoped and restarted.

However, since the local I2C of 913A is stuck, it can not be reset from 914A with I2C.

I have some questions on this phenomenon.

#1

Is it possible that the local I2C of 913A stalls at SCL:High and SDA:Low in the previous situation?

Although the remote slave device is returning an ACK, it seems that 913A has stopped without pulling SCL low.

It is known that when SCL is pulled low in this situation, it will be solved.

#2

Is there a fundamental measure for this matter.

I know that it will solve by 913A hardware reset if it has occured.

We understand that the way to deal with a hardware reset, but first we want to prevent this from occurring fundamentally.

Best regards,

Tomoaki Yoshida

  • 0
    TI__Genius 12866 points
    I will do some bench testing and get back to you.


    Best Regards,
    Charley Cai
  • 0 in reply to Charley Cai
    TI__Genius 12866 points
    Hi,
    This issue might be possible. One possible reason might be that I2C bus is conflict in multi-master condition.
    How many devices are connected to the I2C bus on the 913A side?

    A few possible resolutions would be
    1. Try to speed up the I2C watchgod timeout register 0x0F[1].
    2. If the slave device doesn’t return an ACK, the I2C bus should be freed.


    Best Regards,
    Charley Cai
  • 0 in reply to Charley Cai
    Genius 5255 points

    Hi Charley-san,

    Thank you for your support.

    Two devices are connected to 913A by I2C.

    There is another 913A and FPGA.

    In our case the remote slave device stops returning ACK.

    It is said that this issue might be possible, but could you explain the principle?

    Best regards,

    Tomoaki Yoshida

  • 0 in reply to Tomoaki Yoshida91
    TI__Genius 12866 points
    So there’re three devices on the same I2C line right? Do they all have different I2C addresses?
    913A can serve as both I2C master and slave, and I assume this FPGA could as well. It is possible that two, or all of these three devices are trying to act as the I2C master when the issue happens. When the devices are in multi-master conflicts, SCL will be held by the first master which might not be the active 913A.
    You could try to check if there’s any other device that’s responding on the line.

    Best Regards,
    Charley Cai
  • 0 in reply to Charley Cai
    Genius 5255 points

    Hi Charley-san,

    Thank you for your support.

    We confirmed that there is only FPGA on the same I2C line.

    There are two 913A on the board, but the I2C line is individually connected to the FPGA on a one-to-one basis.

    In the local I2C between 913A and FPGA, the command transfer is over and the FPGA returned ACK to 913A.

    It seems that the 913A can not pull down SCL to low at  9 clock and 913A is holding SCL:Hi and SDA:Low.

    At this time 914 A is losing power or reset, so I think that 913A is freezing because there is no opponent returning Ack.
    In such a case, I think that the I2C bus timer of 913A will help to open the bus, but it will not be released.
    Register 0x0F[0] is set to 0 as default.

    I think that the I2C bus timer is enabled with this setting.
    Is it correct?
    Best regards,
    Tomoaki Yoshida
  • 0 in reply to Tomoaki Yoshida91
    TI__Genius 12866 points
    Yes, the I2C bus timer is enabled by default.
    Have you tried to speed up the timer using 0x0F[1]?

    Best Regards,
    Charley Cai
  • 0 in reply to Charley Cai
    Genius 5255 points

    Hi Charley-san,

    Thank you for your support.

    It is understood that FPGA on 913A board was able to know that the 914A power supply was lost in our system.

    When detecting power loss of the 914A, we will take measures to reset the I2C controller of the FPGA once.

    Because this is considered to be the most certain, we have not been able to challenge the speed up the ti,er using 0x0F[1].

    Best regards,

    Tomoaki Yoshida

  • 0 in reply to Tomoaki Yoshida91
    TI__Intellectual 2930 points
    Yoshida-san

    Has this issue been reolved? If it is please close this thread

    Regards
    Vijay
  • 0 in reply to Vijaya Ceekala
    Genius 5255 points

    Hi Vijay-san,

    Thank you for your reply.

    Yes, we think that this issue has closed.

    Best regards,

    Tomoaki Yoshida