• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 34 subscribers
  • Views 893 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.

TCA4307: I2C Bus Hang Issue Due to Clock Stretching When Adding Multiple Slaves

Dhruvit Bhimani
Intellectual 280 points
Part Number: TCA4307
Other Parts Discussed in Thread: TCAL6416R, TCAL6416

Tool/software:

Hello TI Experts,

We are facing an issue in our I2C master-slave communication setup and need guidance on whether the TCA4307 I2C buffer can resolve it.

System Overview:

  • Master: ESP32-S3
  • Slaves: STM32G0 Controllers (Multiple Slaves)
  • I2C Bus Setup:
    • Pull-up resistors: 4.7kΩ near the master (also tested with 2.2kΩ)
    • Slaves are added one by one dynamically using a plug-and-play concept
    • Default slave address: 0x01 (reassigned dynamically by the master)

Issue Faced:

  1. Initially, we connect Slave 1 (0x01) and later change its address to 0x60.
  2. We then add Slave 2 (0x01) and update its address to 0x61 for independent control.
  3. Problem occurs when adding the second slave (or subsequent ones):
    • The SCL line gets pulled LOW continuously, causing the entire I2C bus to hang.
    • This suggests that one of the slaves is clock-stretching indefinitely, preventing communication.
    • A manual reset of one of the slaves restores communication, but adding a third slave causes the issue again.

Troubleshooting Done:

  • Changed pull-up resistors from 4.7kΩ to 2.2kΩ → Issue remains
  • Verified logic analyzer data → Clock line is being held LOW by one of the devices
  • Suspected cause: Bus capacitance increase or unintended slave behavior during initialization

Possible Solution – Need Confirmation:

We found that TI’s TCA4307 I2C buffer has:

  • Automatic clock and data recovery (prevents bus hang due to clock stretching)
  • Capacitance isolation (reduces bus load when adding new slaves)
  • Hot-swappable support (enables dynamic slave addition without disruption)

We would like to confirm:

  1. Will the TCA4307 resolve our issue with slaves pulling SCL low during plug-and-play operation?
  2. Do we need additional configurations when using TCA4307 for multiple STM32G0 slaves?
  3. Are there any alternate TI solutions better suited for this scenario?

We appreciate any insights or recommendations on how to resolve this issue efficiently.
Thank you in advance for your support!

  • 0
    Guru 317280 points

    The TCA4307 attemps to recover a stuck bus by generating clock pulses. But when the clock is stuck low, this is unlikely to help.

    As far as I can see, a slave with the address 0x60 is not ready. It is likely that the I²C hardware in that MCU keeps SCL low as long as the firmware does not handle the I²C interrupt correctly. You should fix that error. (As a slave, never ignore I²C accesses; return NACK, if possible, or ignore written bytes, or return 0xFF for reads.)

  • 0
    TI__Mastermind 48148 points

    Hi Dhruvit,

    Dhruvit Bhimani said:
    Will the TCA4307 resolve our issue with slaves pulling SCL low during plug-and-play operation?

    As Clemens already mentioned, the TCA4307 helps with stuck bus issues on the SDA line. A stuck clock due to a clock stretching event won't be resolved by the TCA4307. 

    Is it the STM32G0 devices that are clock stretching the bus? What is causing that device to hold the SCL line LOW for that long? 

    I looked up STM32G0 datasheet and couldn't find much documentation on the nature of its clock stretching, although I found one section that says it supports it. 

    Regards,

    Tyler

  • 0 in reply to Tyler Townsend
    Intellectual 280 points

    Hi Tyler

    Thankyou for sharing the features of STM32G030, 

    Yes STM32G030 device is stretching the clock line low. 

    We are trying to free it up from ESP32-S3 master side but slave device is not releasing the control, until resetting the device manually.

    Is that mean this slave device is not sufficient enough to handle this kind of processes?

    If you had any solution to resolve the issue it will be great for our development.

    Regards,

    Dhruvit 

  • 0 in reply to Dhruvit Bhimani
    Guru 317280 points

    I can only suggest to fix the STM firmware, or to add a reset line to the STM.

  • 0 in reply to Dhruvit Bhimani
    TI__Mastermind 48148 points

    Hi Dhruvit,

    I am not familiar with the STM32G030 so I wouldn't have much advice to offer on that side. 

    As Clemens suggested, it seems like a firmware issue with the STM device. If it is not too much to add external /RESET connection to each STM when connecting multiple cards, I think this is a simple solution. 

    If you are worried about IO consumption, you could also expand the # of I/O's of your MCU with a device such as TCAL6416 or TCAL6416R. 

    Regards,

    Tyler

  • 0 in reply to Tyler Townsend
    Intellectual 280 points

    Hi Tayler,

    Thanks for suggestion, I'll update you if I found anything in firmware, if not then reset option is still there.

    Regards,

    Dhruvit

  • 0 in reply to Dhruvit Bhimani
    TI__Mastermind 48148 points

    Hi Dhruvit,

    Looking forward to your response. 

    Regards,

    Tyler

  • 0 in reply to Tyler Townsend
    Intellectual 280 points

    Hi Tayler, Clemens,

    The issue has been resolved.

    Previously, I evaluated the power rails on the DSO, and there was no noticeable dip. However, in our custom hardware, we have the option to solder additional capacitors if needed.

    I have placed tantalum capacitors of 100µF and 470µF on the power rails of the 3.3V supply.

    Both capacitor values are useful; I have tested with both. I placed one tantalum capacitor near each slave device. Since I tested with five slave devices, I used five tantalum capacitors. I first tested with 470µF, followed by 100µF, and both worked well.

    We tested the same hot-swapping method with multiple customized STM32G030 slave devices on a running ESP32 I2C line approximately 100 times.

    Not once did the clock line get stretched.

    This could be a really effective solution for other developers as well.

    Best regards,
    Dhruvit