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.
