STM32G070CBT I2C Bootloader Issue Difference Between Revision B and Y

[bkaratas]

Hi,

We are using an ESP32-S3 device as the I2C master to communicate with STM32G070CBT processors operating in I2C bootloader mode. We have two revisions (Revision B and Revision Y) of the STM32G070CBT processors.

When probing the STM32 I2C bootloader at address 0x51, Revision B responds successfully without any issues. However, using the exact same hardware and configuration, Revision Y fails to respond, resulting in an I2C transaction timeout:

E (13891) i2c.master: I2C transaction timeout detected
E (13891) i2c.master: probe device timeout. Please check if xfer_timeout_ms and pull-ups are correctly set up

Important details:

• We confirmed the STM32 bootloader mode is enabled correctly for both revisions.

• Hardware connections and pull-up resistors remain identical.

• Lowering I2C speed to 100 kHz doesn't resolve the issue.

• Issue specifically arises when using ESP32-S3 with ESP-IDF's latest I2C driver. Older versions of the ESP-IDF I2C driver do not exhibit this problem.

We suspect there may be subtle differences between STM32G070 Revision B and Revision Y regarding their I2C bootloader implementation. Could there be differences in I2C bootloader behavior or timing requirements between these revisions? Any guidance or documentation highlighting potential differences between these revisions would be greatly appreciated.

Thank you for your support.

[TDK]

Did you check the bootloader version? There is this interesting note in the version changes.

You could also download the contents of the system flash with STM32CubeProgrammer and compare them.

[bkaratas]

We read the bootloader version using CubeProgrammer. Revision Y appears as v11.3, while Revision B appears as v11.2.

In the AN2606 document, the difference is noted as:
"Compatibility break on boot sequence versus older versions."

As a result, an initialization of hardware peripherals step has been added to the bootloader sequence.

How could this difference impact the behavior?

Note: The tests were conducted after performing a full chip erase on both Revision B and Revision Y boards.

[TDK]

I can't see how that would affect the results you're seeing.

Can you look at the signals on the I2C lines? Since these are not the same hardware, can you swap one chip to the other board to test?

[bkaratas]

Yes, here are the logic analyzer captures of the I2C lines for both Revision B and Revision Y:

• Revision B: 
  

• Revision Y: 
  

We observed clock stretching on the I2C SCL line with Revision Y.

The tests were performed using the same board by only swapping the ST modules. Additionally, we tested using a different board, and the result remained the same. The behavior consistently persisted.

[TDK]

Interesting. It looks like rev B also stretches the clock, but only for a fraction of a bit.

I2C doesn't have a timeout though, and it eventually does release SCL after 70 ms and the transaction is successfully ACKd, according to the logic analyzer.

So while the behavior is definitely different, I'm not convinced it's invalid. Can you disable or extend the I2C timeout time on whatever is driving the I2C bus?

[bkaratas]

When we increased the timeout on the device driving the I2C bus, the issue was resolved. However, as you've observed, the SCL stretching duration (around 70 ms) is significantly longer compared to the probes made to other addresses. Are you planning any adjustments or changes regarding this behavior?

[TDK]

The bootloader is in ROM and can't be changed on existing chips. So that's right out.

As for future changes: In my opinion (and I don't work for ST), there is nothing requiring a change as the bootloader functions as documented, but 70ms is a bit long and probably it could be improved, but I don't know the details here. It's probably not a priority.

The other addresses don't have a clock stretch because there is no slave at that address.