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.

TCA9548A: Ways to unblock I2C path

Part Number: TCA9548A

Tool/software:

Hi,

In one of our designs, we’re using this component to isolate the I2C paths to our slave ICs. The goal is to prevent a single I2C slave failure from disabling the entire I2C bus.

For example, if one of the slave ICs fails and pulls the SDA line low (e.g., shorted to GND), the entire I2C bus would become non-functional, and communication with all other devices would be lost.

Looking at the functional block diagram of the TCA9548A, it seems that if a slave device connected to an active channel fails in this way, it could also block access to the TCA9548A’s I2C control interface. Is that correct? If so, would the only way to recover the I2C bus be to reset the TCA9548A and disable the faulty channel?

Thanks in advance for your help!

  • Hi Marcos,

    Actually taking a look into this the TCA9548A is a good device for this kind of application.

    This is because while the i2c bus communication might have issues when the SDA is pulled down by a faulty slave the controller device connected and the channel is is connected to is enabled , the TCA9548A control register  can still control the switch and disable the channel of connected to the faulty slave  effectively isolating it from the rest of the system.

    The Faulty slave connected to the TCA9548A will not affect the ability of the actual  TCA9548A control register to work properly.

    To disable the channel connected to a faulty slave just write to the TCA9548A's control register via the main SDA and SCL lines  and  disable that specific channel.

    You could also use the reset pin to disable all the channels of the TCA9548A and begin i2c communication again while avoiding the faulty slave because the channel it is connected to will be disabled.

    The control register of the TCA9548A is not affected by the faulty slave but please let me know if I misunderstood your question and I can think about this more.

  • Hello, Kameron,

    I am Jessica Vílchez, Marcos' colleague. Thank you for your reply!

    So, will there be no problem even if the selected slave ties the SDA, for example, to GND? Considering the functional diagram in section 7.2 of the datasheet, it seems that when a slave is selected, its SDA+SCL lines are ‘directly connected’ to the main SDA+SCL lines (TCA9548 inputs). So how can you rewrite through these I2C lines to change the control register if one of them is tied to GND?

    In this situation, is there any other solution apart from resetting the TCA9548 to deselect the current slave? Would the TCA9548 be able to detect this problem and release the slave to allow the control register to be overwritten?

    I look forward to your reply. Thank you again!

  • Hello, Kameron,

    I am Jessica Vílchez, Marcos' colleague. Thank you for your reply!

    So, will there be no problem even if the selected slave ties the SDA, for example, to GND? Considering the functional diagram in section 7.2 of the datasheet, it seems that when a slave is selected, its SDA+SCL lines are ‘directly connected’ to the main SDA+SCL lines (TCA9548 inputs). So how can you rewrite through these I2C lines to change the control register if one of them is tied to GND?

    In this situation, is there any other solution apart from resetting the TCA9548 to deselect the current slave? Would the TCA9548 be able to detect this problem and release the slave to allow the control register to be overwritten?

    I look forward to your reply. Thank you again!

    Translated with DeepL.com (free version)

  • Hi Jessica,

    Thank you for your detail reply and now reading your response I see that I misunderstood your question.

    You are correct that when a slave device pulls the SDA line low the communication from the controller to the TCA9548A will not work properly and that bus is stuck.

    The only solution to this stuck bus issue is like you mentioned which is resetting the TCA9548A  and disabling the fault slave  channel.

    This stuck bus issue due to faulty slave devices is common with in band controlled switches like the TCA9548A

    In addition the TCA9548A doesnt detect stuck bus and stuck bus detection is typically the job of the controller device in the system.

    Here is more information on how you can implement other devices into your design to prevent stuck buses.

    Finally if you would like to look at other multiplexer/ switch options that have something called out band control( select pin control) and might offer a different solution here please look at our teams analog multiplexers

     [FAQ] What Analog Switch / Multiplexer should I use for I2C applications? 

    https://www.ti.com/lit/po/sllt232/sllt232.pdf?ts=1753462407002&ref_url=https%253A%252F%252Fwww.google.com%252F

    Please let me know if this helps clarify anything and happy to discuss this more.

    Regards,

    Kameron

  • Thanks for getting back to us. That clears things up!