I2C CLK Hold Issue During Initial Communication on Recent STM32 MCU Builds

[Saideepak]

Usually, fresh (no firmware) STM32 MCUs will be in bootloader mode by default without needing to toggle the boot and reset pins. In such cases, we proceed directly with the firmware update procedure using the default slave address (0x5d).

However, we have encountered an issue with some of the recent build STM32G0 series MCUs. These units are not in bootloader mode by default. When we attempt to do firmware update using the default slave address (0x5d), the MCU holds the I2C clock line and does not release the bus until we manually toggle the boot and reset pins to bring the MCU into bootloader mode.

In the past, fresh MCUs would automatically be in bootloader mode, allowing us to proceed with the firmware update seamlessly. Given this change, we suspect there may be some base firmware present in these MCUs that is holding the I2C clock line when we attempt communication with the default slave address (0x5d).

Could you provide us with insights on why some of the recent build STM32G0 MCUs are not in bootloader mode by default? Is there a base firmware pre-installed that could be causing this behavior?

We would appreciate any guidance or support you can provide and I looking forward for your response.

[Amel NASRI]

Hi @Saideepak ,

I'm not aware about any change related to bootloader for recent STM32G0 MCUs.

To farther investigate, may you share flash dump of 2 devices: the working properly one and the failing one?

Which STM32G0 part are you using?

Is issue faced with some devices or all recent ones?

-Amel

[Amel NASRI]

Hi @Saideepak ,

Please discard my previous reply. I correct what I said to share with you a known limitation on latest bootloader version (V11.3) that created a compatibility break on boot sequence versus older versions.

This is well described on page 223 of AN2606 rev 64.

Please check your bootloader revision and try to avoid any reset in bootloader process.

-Amel

[Saideepak]

Hi @Amel NASRI ,

Which STM32G0 part are you using?

Is issue faced with some devices or all recent ones?

I am facing this issue in 25% of mcu boards.

Bootloader version - 0x12(For I2C protocol V1.2)

I have another batch mcu where the mcu is not entering the bootloader mode even after making boot pin high. I have attached its image and description below,

We are encountering an issue with STM32G0B1KEU6 microcontrollers from two different batches, where one batch is successfully entering bootloader mode after making the BOOT pin high and toggling the RESET pin (low to high), while the other batch fails to do so, even with the same handling.

Here are the details of the two batches:

• First Batch 20% (MCU entering bootloader mode successfully after BOOT/RESET pin handling):
• Marking: 32G0B1KEU6
• Code: 6024H 1K9R
• CHN 328 Z (Image attached)
• Second Batch 100% (MCU not entering bootloader mode, despite correct BOOT/RESET pin handling):
• Marking: 32G0B1KEU6
• Code: 6Q246 129R
• CHN 222 A (Image attached)

Issue Description:

• For the first batch, the MCU enters bootloader mode as expected when we bring the BOOT pin high and toggle the RESET pin from low to high.
• For the second batch, following the same procedure does not result in bootloader mode. Additionally, the MCU holds the I2C clock line and does not respond at the default bootloader slave address (0x5d).

We suspect there may be differences in the configuration between these two batches, such as silicon revisions, option byte settings, or pre-installed firmware, that are affecting the bootloader behaviour.

I also tried the workaround avoids resets (except POR or option byte change). Handling only boot pins still the MCU holds the I2C clock line and does not respond at the default bootloader slave address (0x5d).

We appreciate your assistance in resolving this issue and any documentation or resources you can provide.

Thank you for your support.

[Amel NASRI]

Hi @Saideepak ,

Face to current situation, the recommendation I can give is to have contact with your FAE and start a FAR (Failure Analysis Request) to understand the problems root-causes.

Keep us informed.

-Amel