Flash via I2C bootloader problem for STM32G0B1KBU6

[IE]

Hello,

We encountered a problem with the internal Bootloader of the STM32G0B1KBU6 MCU.

Conditions

First, the option bytes are set with an STLINK-V3 programming adapter (SWD interface) and CubeProgrammer (2.15.0) according to Pattern 11 of AN2606:

nBoot_SEL => unchecked
nboot1 => checked
nboot0 => unchecked

Reproduction

1. In our product assembly process:
Initial programming of the user software is successful with STLINK-V3 Programming Adapter via SWD interface. Stm32flashtool is used to flash the controller at I2C address 0x5d. Pin PB6 and PB7 are used to access I2C bootloader.

2. Trying to reprogram the controller while testing:
Now, with the software already running on STM32G0B1KBU6 (verified) we go through the STM bootloader activation Pattern 11 (AN2606, Sec. 4.1) with pulling boot0 and reset low, then pulling boot0 and afterwards reset high.

Expected

3. MCU is reflashable via I2C bus.

Observed

3. As soon as the bootloader is addressed by an erase or flash command with the stm32flash tool, the level of I2C clock drops to zero permanently and communication with the MCU or other I2C devices is not possible.

Workarounds

The only workaround we have is hardware resetting the MCU after a power cycle while boot0 and reset pin are permanently set high. After a few erase and flash commands via I2C at address 0x5d, the memory flash is permanently erasable and flashable without breaking the I2C bus’s clock.

This problem also only occurred for 3 out of 10 boards. 7 MCUs are programmable while software is running.

Is there any known issue with I2C Bootloader similar to ours?

Thanks a lot in advance!

[TDK]

> If clock stretching is enabled, shouldn't it recover at some point?

If you're not following the bootloader commands, behavior is undefined.

Probably isn't ideal that the I2C bus is active during the reset period, but perhaps not the issue.

[IE]

Hello,

the problem still occurs.  MCUs were programmable on PCB board via I2C and stm32flashtool before assembling. After the protective coating of the circuit board and the assembly of the product, we receive I2C write error messages on the bus as soon as the bootloader is addressed for erasing or flashing. Here also the level of I2C clock drops to zero permanently and communication with the MCU or other I2C devices is not possible.

[MM..1]

Maybe your protective coating have some conductivity. Try clean up with som cleaner and try if works back.

[IE · Accepted solution]

We have finally found the root of the problem. Pin 23 (PA12[PA10]), which is responsible for the DFU bootloader, was not defined up until now.
If this is set to GND via 10kOhm and a reset is carried out via the reset pin, the I2C clock can occasionally be reproduced. Presumably because the DFU bootloader is activated as a result? We did not assume that this pin plays a relevant role, as according to AN2606 it can only be activated by the following condition: "VDDUSB IO must be connected to 3.3 V as USB peripheral is used by the bootloader." If we set PA12 high using a pull-up resistor, the error no longer occurs.