STM32G0 don't start and connect after update

[YDann.7]

Dear,

I have a big problem on a STM32G070 and I don't know what I can do to solve it.

The system is composed of 2 boards with a STM32G0B1 for the first (master board) and a STM32G070 for the second (slave board).

The 2 MCUs are connected by UART and this link is used to update the slave MCU by the first using the STM32 bootloader.

The setup was the first MCU (master) programmed with the firmware and the MCU (slave) full erase with the default option byte value.

In a first time, I programmed the slave MCU with the STM32 UART bootloader from the master mcu and it was OK. The slave MCU worked well. I rewrite the option byte of the slave MCU by the firmware to be able to used the GPIO BOOT 0 pin as legacy mode.

In a second time, I tried to upgrade again the slave MCU using the master and it doesn't worked. I don't removed the power of the boards between this 2 tries.

And now, I'm not able to connect to the slave MCU using STM32CubeProgrammer.

I have "Error: No STM32 target found!" and "Voltage: 0.01V" even if I have 3.3V on the pin 1 of the SWD connector and a high level on the NRST pin. I also tried some differents "Mode" and "Reset mode" configuration without success.

And now I don't know what can I try to do come back to life this MCU.

[YDann.7]

@Sco​ On the R22 resistor, I have 0V. But I use an old ST-Link cutted from an STM32F030R8 nucleo board. And this resistor is connected to the pin 6 (SWO - Reserved)

So, the component denomination could be different.

If I compare a nucleo schematic and mine, the "AIN_1" signal seems to be connected to the debug connector (pin 1) through a resistor not fitted. On my ST-Link, it seems to be the resistor R9 (not fitted) and I have 3.3V on it.

@TDK​ My slave board is powered by the master through a FPC cable. And the slave board (MCU) is correctly powered. I didn't change something between the 2 try.

[YDann.7]

I did another try with 2 others boards in the same setup. I added a power OFF / power ON sequence between the update. And it seems to work (I need to do some more test).

The problem seems to be on the options bytes.

When I do the first update, the slave MCU is full erase with its default option byte. After this update, the slave MCU reset (using NRST pin controlled by the master) and the applicative firmware run. At the beginning of this firmware, I rewrite the option byte to configure "nBOOT0 bit" at 0 to be able to use the BOOT0 pin in legacy mode.

And without doing an "OBL_LAUNCH" bit or a power reset, the master restart the slave board in STM32Bootloader using "legacy mode" to an update again. Without success and after that, I have no access to the slave MCU.

[YDann.7]

It's seems to be something wrong with with the option byte.

If the slave board firmware" launch the option byte loading" using the "HAL_FLASH_OB_Launch" function of the drivers library, I'm able to do a second update with the the STM32 UART bootloader.

In the reference manual RM0454, I don't see anything about this.

It's mentionned that the option bytes loading is performed in 2 cases (OBL_LAUNCH bit and a power reset) but without the necessity to do it.

It also mentionned the device can be permanently lock if there is an option byte programming failure (loss of power or a reset during the option byte change sequence) but i'm not in this case.

In my case, I wrote the option bytes to be able to use the legacy mode for the pin "BOOT0" and without reloaded it, I tried to do an update using legacy mode access to the STM32 bootloader. Nothing happened and now the MCU is completely blocked. I don't have access it by not means.

I consider that as a criticial bug.

It's too easy to completely blocked a MCU without possibility to unlock it.

@Sco​ Maybe you can check with the ST technical engineers this "potential" problem beacause I think I'm not alone in this case and some other people can have the same problem.