I²C Bus Stuck Issue – STM32G0 Slave Holding SCL Low During Hot-Swapping

[dhruvit]

Hello ST Experts,

We are implementing a hot-swappable (plug-and-play) I²C system with STM32G0 slaves, but we are facing an issue where the I²C bus gets stuck due to SCL being held LOW. We need guidance on how to resolve this.

System Overview:

• Master: ESP32-S3
• Slaves: STM32G0 Controllers (Multiple Slaves)
• I²C Bus Setup:
  • Pull-up resistors: 4.7kΩ near the master (also tested with 2.2kΩ)
  • Slaves are added dynamically using a hot-swapping (plug-and-play) approach
  • Default slave address: 0x01 (each slave is reassigned a unique address by the master)

Issue Faced:

1. Initially, we connect Slave 1 (0x01) and later reassign its address to 0x60.
2. We then add Slave 2 (0x01) and update its address to 0x61 for independent control.
3. Problem: When adding the second or subsequent slaves, the SCL line gets pulled LOW continuously, causing the I²C bus to get stuck.
   • This suggests that one of the slaves is clock-stretching indefinitely, preventing further communication.
   • A manual reset of the stuck slave restores communication, but adding another slave causes the issue again.

Troubleshooting Done:

:white_heavy_check_mark: Changed pull-up resistors from 4.7kΩ to 2.2kΩ → Issue persists
:white_heavy_check_mark: Verified with a logic analyzer → SCL line is being held low by a slave
:white_heavy_check_mark: Suspected bus capacitance or unintended slave behavior during initialization

Key Concern:

• Hot-swappable I²C systems must ensure that newly inserted devices do not interfere with ongoing communication.
• However, in our case, once a slave pulls the SCL line low, neither the master nor any other device can free it up.
• This could be due to an issue in STM32G0 firmware, where the slave isn’t handling I²C accesses correctly after an address reassignment.
• If the slave is not ready, it should return a NACK or ignore data, but instead, it seems to hold the SCL low indefinitely (clock stretching without release).

Questions:

1. What could cause the STM32G0 to hold SCL low permanently? Could it be an issue with firmware initialization or interrupt handling?
2. How can we ensure that a slave does not stall the I²C bus, especially in a hot-swapping environment?
3. Is there a proper way to handle I²C address reassignment on the STM32G0 to avoid this issue?
4. Are there any known fixes or best practices to prevent an STM32G0 slave from indefinitely holding SCL low?

Since this is a hot-swappable system, we are particularly interested in techniques to ensure newly connected I²C slaves do not interfere with the ongoing communication.

Any insights or recommendations would be highly appreciated. Thank you in advance for your support!

[TDK]

Debug the slave code and see where it’s stuck and why. Slave will stretch clock if ADDR is acknowledged and slave is waiting to know what to do.

Sure is a long post without much info. Is AI really improving the presentation here?

[dhruvit]

Hi TDK,

Thanks for replying

Let me explain further more, about integration of hardware.

As you can see in image we have selected ESP32-S3 devkit as master who control STM32G0 dev kit as slave, 

1. Here i have soldered all 3 board on general purpose PCB, with PB6 pin as SCL and PB7 pin as SDA of STM32G0

2. Ground common of all the boards with +5V supply given on VIN pin of STM32G0 from ESP32-S3

3. And inserting the STM32G0 board in female socket one by one, while ESP32-S3 is already plugged in the BUS.

4. Here STM32G0's supply and i2c pins are connecting with BUS at same time. 

4. Connected logic analyzer on SDA and SCL Pin

5. External pull-up is 4.7k on master side 

6. After powering on the master 1st we inserting 1 slave and commissioning with master by changing its default address 0x01 to 0x60.

7. After successful commissioning we test the set of command which STM32G0 need to do as master using i2c.

As you can see in logic screenshot one of slave is pulling low the i2c clock line while I inserting 2nd slave.

To free-up i2c buss we are sending stop signal from master but it does not accept as clock is pulled low.

When I reset one of slave the clock line getting back to original state, and we can further commission 2nd slave.

This is the configuration which we have used, better known as plug and play (hot swap) concept.

The strange thing we have noticed that if we do not disconnect i2c pins from master and keep it connected while only plug or remove USB in to STM32G0, this problem never accrued. 

I am assuming that on board STLINK (STM32F) debugger which is present on the board might resting the board automatically whenever required. (not sure)

Is it possible ?

For hardware solution we have think about putting i2c buss buffer in all slaves but this might not solve the problem said by ti expert https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1483267/tca4307-i2c-bus-hang-issue-due-to-clock-stretching-when-adding-multiple-slaves/5696091#5696091 

Regarding slave debugging 

In my code, I am continuously monitoring the slave, from the master if any external input command has given to slave by user or not.

Further I'm debugging code for more details as you suggest.

Regards.

[dhruvit]

Hi TDK,

As you suggested, I put the STM32G0 board in debugging mode to check where it is getting stuck. However, I found something strange while in debugging mode, the issue does not occur at all.

But when I disable debugging mode and test with the above hardware configuration, the issue sometimes occurs, but not always. It seems to be a worst-case scenario, meaning the bus does not get stuck every time, but it happens intermittently.

Any thoughts on why this might be happening?

Regards.

[TDK]

Okay, so you're doing an I2C transaction every 0.2ms, or at about 5000 Hz.

As a side note: It looks like the master doesn't respect the clock stretching, as it's still toggling SDA even though it's not allowed per the I2C spec.

The underlying cause is almost certainly a bug in the slave I2C code where the address match isn't handled appropriately. It would make the most sense to try and figure out where and why that's occurring and fix it.

As a band aid, you could disable stretching and see if it works. Probably that will just produce errors.

You can attach a debugger to a chip that is already running without resetting it. I would do that to see where the code is stuck and why. Examining the state of the i2c handle would be helpful here.

Attaching to a Running Target with STM32CubeIDE Debugger | kzeise.com