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.

TCA9546A: I2C BUS failure mode

Part Number: TCA9546A
Other Parts Discussed in Thread: PCA9546A

Tool/software:

Hi, we encountered an I2C issue that appears to be related to abnormal behavior of the PCA9546. When the issue occurs, all I2C bus devices become non-functional. The system recovers only after power-cycling the LED board, which includes the PCA9546, PCA9552, AT24C02, and TMP75A.

 

Currently, we've shipped over 2,000 systems, and this failure has been observed on 6 units, all of which were running for extended periods before encountering the issue.

 

Could you please share known failure modes of the PCA9546, particularly under long-term operational conditions? We're looking for insight into whether this behavior could result from factors such as thermal stress, voltage spikes, I2C bus contention, or internal latch-up, and whether there are any recommended mitigations or known errata.

 

Thank you for your support.

 

  • Hi Jay,

    Happy to help here and just wanted to ask a couple questions to get a better since of whats the issue here.

    1. Are you using the TCA9546A or PCA9546 in your design?( It looks as if you are using the TCA9546A but i just want to make sure)

    2.Could you tell me more about the failures you are seeing and how do you know it is the  PCA9546 or TCA9546A causing the issue.

    Do you have any waveforms and scopeshots of the issue? Also do you have a more detailed schematic diagram of the PCA9546 or TCA9546A. This can help us debug the hardware.

    To my knowledge these devices are passive i2c switches that allow communication bidirectionally on the bus and therefore should not cause things like the bus to stop operating after a extended period of time

    However please let me know what you think of this initial information and any additional info can help us debug here.

    Regards,

    Kameron

  • 1. Yes, TCA9546A, Apology for the TYPO in description.

    2. We remove the LED module and get this channel back to normal. the LED module include 4 I2C devices but 3 devices mount on TCA9546, the MCU process will switch the channel if the device not response but the MCU pending on all device even it switch to different channel.

    The machine already shipping out around 2years and no issue there, recently it occurred this issue after it power on around 2weeks, we think it normal failure because long time support without any reset or power cycle may have some abnormal behavior, that's why we ask for the failure mode condition.

    Attached the schematic for reference.

    4477.sch.pdf

  • Hi Jay,

    I have some other questions to help us narrow down what might be happening here.

    1.Does the mean that every device connected to the TCA9546A or PCA9546 is sending a NACK Bit?( Do you have any scopeshots or waveforms of the i2c communication here?

    but the MCU pending on all device even it switch to different channel.

    2.I assume this means that multiple units of the system in the picture have shipped out and it is only recently this error has occurred?

    How many times has error occurred with the i2c switch powered on for 2 weeks? How many units has this error happened with? During the 2 weeks is the device passing I2C signals/ is I2C communication happening continuously for 2 weeks

    The machine already shipping out around 2years and no issue there, recently it occurred this issue after it power on around 2week

    3.The schematic for the PCA9546 looks correct and no issues are there however can you send the schematic for the TCA9546A?

    4.Have you tried multiple units to replace the PCA9546 or TCA9546A on the board that is failing?

    Finally looking into this I did find a reason why this device would stop operating properly after being powered on for 2 weeks( Under recommended operating conditions)

    Please let me know what you think about these questions and we can discuss.

    Regards

    Kameron

  • Hi Kameron

    1. The machine fail on field site, we can't get the waveform it  and it would recover after power cycle, we had get the system back but not occur anymore.

    2. only one time.

    3. It's same, we have 2 source for it PCA9546A & TCA9546A.

    4. We are try multiple units but not able to reproduce it yet.

  • Hi jay,

    Understood

    The schematic looks good and i didn't find any failure for the TCA9546 or pca9546 that could be related to your issue.

    However in the future if you have any other concerns with this part please let our team know.

    Regards,

    Kameron

  • Hi Kameron

    This is we want to know.

    Could you please share known failure modes of the TCA9546, particularly under long-term operational conditions? 

  • Hi Jay,

    Looking into this more there are no failure modes for this device under long term conditions if this device is used in the recommended operating conditions outlined in the datasheet

    Regards,

    Kameron

  • Do you mean it never to hung on I2C after long term condition? As I know, every I2C device may get hung after tens of thousands read/write command.

  • Understood,

    So a I2C hung bus or stuck bus could occur with the multiple i2c devices on it but it is more of a system issue and can be caused by several factors including faulty hardware.

    If the TCA9546A or PCA9546 are used in the recommended operating conditions I'm not sure if those would be the direct reasons why issues would happen on the bus.

    For this application we are talking about I see the schematic looks ok and if I am not mistaken this error isnt reproducible right now so there isnt much information to say why any failure happened and we cannot confirm to say it was the TCA or PCA9546 fault.

    If the device was exposed to operating conditions outside recommended operating conditions which would lead to damage or the i2c bus design lead to a stuck bus then TCA9546 or PCA9546 could be part of a design that had a stuck bus.

    Based of the information you shared I don't think the PCA or TCA9546 devices are the issue here because it is not reproducible error

    Is there something that makes you think this because we would have to have more information on the issue like waveforms to diagnose and see if the TCA or PCA is the issue

    Regards

    Kameron

  • That's why I'm checking for the failure mode, for example, we give noise on I2C bus and TCA9546 would latch up the SDA to low level, multiple device on same bus would get many high/low signal and it also include some unknown signal level , it cause of the ACK by different device. Please help to offer some possibility failure condition of TCA9546 that's help us to improve our software to avoid any unexpected issue occurred, thanks for support.

  • Hi Jay,

    I think what you just described is a failure mode that can happen on the bus with the TCA9546A

     If the DataStream to the TCA9546A were to be corrupted by a false clock edge, then potentially the TCA9546A can hold the SDA bus LOW.

     But the false clock edge would be a result of system design or a bad clock signal from the host controller  which isnt the TCA9546a fault.

    Im not a expert in I2C bus design however looking into the firmware of the controller device on your bus is a good idea  to potentially prevent this issue.

    Regards,

    Kameron

  • Except to the bus noise to cause the SDA tie to low, any others? for example, supply power not stable or grounding not well, is it cause the bus at Hi-Z or some unexpect condition?

  • Hi Jay 

    Understood 

    Checkout this app note that talks about different ways to prevent failures with i2c devices like the  TCA9546A  

    This should give you a different idea of failure modes.

    Regards,

    Kameron