• State TI Thinks Resolved
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 34 subscribers
  • Views 149 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TCA9548A: I2C MUX channels are not detecting when any one of the slave device is OFF

Ammasi Kani
Prodigy 10 points
Part Number: TCA9548A

Tool/software:

Hi, 

  I am using 8-Channel I2C Switch (TCA9548A), where I am connecting all the 8 channels to 8-slave devices individually.

We are facing issue with the I2C switch operation, as it is not working when one of our slave device (CH-1, Jetson AGX ORIN processor) made OFF in the run time.

As Jetson AGX ORIN (CH-1) we have not provided external pull up for this CH-1.

Observations:

Once Jetson AGX ORIN processor (CH-1) is made OFF, the I2C switch is detecting the CH-0 device but failed to select the channel CH-1 and so on for the first iteration. But for the

next iteration all are getting failed.

Note:

  We need to your support to resolve this issue.

Attached here the schematic of the I2C switch IC.

Regards,

Ammasi Kani V

  • 0
    Guru 316470 points

    I suspect that the Orin, when powered off, pulls both I²C signal lines low. This prevents any I²C communication, including communication with the TCA9548A itself.

    You need proper error handling. When the TCA9548A does not react, reset it.

  • 0
    TI__Intellectual 2765 points

    Hi Ammasi,

    Echoing what Clemens wrote, you should try resetting the device and see if that resolves your issue.

    Best,
    Katy

  • 0 in reply to Clemens Ladisch
    Prodigy 10 points

    Hi & ,

        1. When we probe the I2C lines after powering OFF the Orin, we see 'high' on both SCL/SDA lines.  

        2. We did reset the TCA9548A device when the ORIN is OFF, but as previously said, still it failed to detect the devices on all the channels.

  • 0 in reply to Ammasi Kani
    Guru 316470 points

    Does the I²C communictation to the TCA9548A itself still work? Please show an oscilloscope trace of SDA and SCL.

  • 0 in reply to Clemens Ladisch
    Prodigy 10 points

    Hi  ,

         We do not have the probing point between the SOM module and TCA9548A. 

    We have checked through the software that TCA9548A indeed down and not responding when the ORIN is OFF.

  • 0 in reply to Ammasi Kani
    TI__Intellectual 2765 points

    Hi Ammasi,

    Do you have a way of checking if the I2C communication that is being sent to the TCA9548A from "COMe" is good? It is important to verify that the information that the TCA9548A is receiving at the inputs is correct.

    Best,
    Katy

  • 0 in reply to Katy West
    Prodigy 10 points

    Hi Katy West,

         The information we sent from COMe to TCA9548A is indeed correct, because of the following:

    1. When the ORIN module is powered ON, the I2C communication from COMe to all the peripherals happens without any issue.

    2. When the ORIN module is powered down, the I2C communication from COMe to any of the peripherals doesn't work.

    3. If we power up the ORIN module again, the I2C communication from COMe to all the peripherals happens without any issue.

    We run the same I2C test script in the above tests.

  • 0 in reply to Ammasi Kani
    TI__Intellectual 2765 points

    Hi Ammasi,

    If you never select the ORIN, but turn the ORIN off, does the device work properly? For example, if the ORIN is off and you try to write on channel 6 then channel 7?

    I suspect that when turned off, the ORIN just pulls Channel 1 high, overwriting COMe which is trying write to Channel 1.

    Best,
    Katy

  • 0 in reply to Katy West
    Prodigy 10 points

    Hi ,

        Yes, when we never select the ORIN, but just turn ORIN OFF, the device works properly.

    The default state of the SDA/SCL lines are "high" even when the ORIN is ON and OFF.

    Observation:

    When ORIN is OFF, if we select the ORIN channel first from SW and then any other channel, MUX is failed to detect the respective channels.

  • 0 in reply to Ammasi Kani
    TI__Intellectual 2765 points

    Hi Ammasi,

    We really cannot diagnose anything else without scopeshots. It seems that the Orin is the issue and might be driving the reset pin or overriding whatever data is trying to be sent on SDA but holding it high.

    It would be good to verify if you can communicate directly from COMe to the Orin without the TCA, but again we won't be able to help debug anything else without scope shots.


    Best,
    Katy