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]

Are you sure it's not just holding SCL low during the write/erase, then releasing afterward? That's expected behavior.

Use the no-stretch commands and poll for completing if your master doesn't like this.

https://www.st.com/resource/en/application_note/an4221-i2c-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

[IE]

Hi TDK,

unfortunately the SCL is not released after write/erase command in our observed behaviour. SCL stays low without recovering unless the hardware is reset by a power cycle. Nonetheless we'll try out the no-stretch commands.

[IE]

Hello again,

even non-stretch commands (non-stretch memory erase command) drop the SCL to zero without recovering. SCL stays low, when master is disconnected. Here are 2 pictures of the signals captured with an oscilloscope. First picture shows an successful erase (workaround), second picture shows the SCL failure of non-stretch memory erase command.

blue -> boot0 pin, red -> reset pin , yellow -> I2C SCL, green -> I2C SDA

erase success (workaround)erase fail

[TDK]

Okay, so SCL is being stretched on the next command. Can you show the full transaction, starting with NRST rising edge?

Not saying there isn't an issue, but the plot you've shown only shows that clock stretching is happening which isn't an issue in itself.

A non-stretch memory command requires polling for an ACK byte before the next command is sent, which isn't shown.

> then pulling boot0 and afterwards reset high.

Are you driving NRST high or putting it in high-impedance mode? If you're driving it high, that could be a problem as the chip can't reset itself.

[IE]

The clock stretching begins even with no-stretch commands. The erase fail.png attached is captured after sending the first two bytes. I use i2ctransfer command to send these two bytes to address 0x5d as follows:

i2ctransfer 1  w2@0x5d 0x45 0xBA

As I said, the clock is not recovering unless a Power Cycle is done. If clock stretching is enabled, shouldn't it recover at some point?

The bootloader is enabled by pulling mcu reset low, putting boot0 on high, then releasing reset pin. This is all done by an GPIO-Extender, which is also addressed by I2C. See pictures underneath.

enable mcu reset

 

enable boot0

 

release mcu reset

 

 

[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]

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.