In the STM32G031 do you need to set any pins a certain way to be able to reprogram the chip with ST-LINK or with the Bootloader?

[KiptonM]

I had PA13 and PA13 set as a GPIO. I was able to program it one time with both the ST-Link V2 Clone, a.k.a Blue Pill, and via the Bootloader program stm32flash (on SorceForge.net) using the UART.

Both would only work on a new chip. Once the chip was programmed neither one would work again on that chip.

I can understand that the ST-LINK probably needs PA14 (boot) to be set as SYS_SWCLK and PA13 needs to be SYS_SWDIO for the ST-LINK to work while it is running.

But I would have thought by using the bootloader and setting BOOT0 high before releasing (bringing it high) NRST (Reset) the chip would go directly to the Bootloader and be unaware of anything you set the BOOT0 pin to in the user code.

None of the bootloader documentation says anything about reserving any pins for any function that I have seen. If it is there then it needs to be clearer, because I do not see it.

What do I have to do to be able to reprogram the chip with the bootloader a second time? We want to be able to upload new firmware once installed without tearing the equipment apart.

[Tesla DeLorean]

Does your clone provide a reset signal so you could ''connect under reset" the device?

Reprogramming PA13/PA14 on a low pin count device is going to make connectivity difficult. Perhaps have options within your own code/application, to either not do that, change the settings back to normal, or wait several hundred ms before reconfiguring them after starting to give the debugger a window to connect.

G0 probably also has Option Bytes related to boot/boot modes.

Other options would be methods you add to either remove/erase your firmware, or jump into the boot loader so that also could be used or act as safe-harbor from which to program.

[KiptonM]

Yes we have brought out the Reset Pin, Boot0 Pin UART2_TX, UART2_RX, I2C1_SDA and I2C1_SCK to our programming header, for a SBC Linux Computer (BeagleBone Black) to be able to program the STM32G031.

I am going to look at the Option Bits. I cannot believe they would let me write over the System Memory with my default STM32CubeIDE configuration.

[S.Ma]

Put few seconds delay before recpnfiguring the debug pins so you can recover by power cycling, even in low power mode. Later, optimize.

[KiptonM]

Thanks, I will try that.

[KiptonM]

The UART sends the 0x7F for baud rate detection 210 ms after the NRESET goes high, (Boot0 is high)

It tries again about 500 ms later. There is no response from the STM32.

[MM..1]

Read AN2606 and dont mix SWD with system loader.

After first load or before you need meet Pattern 11 for boot to system ...

or can jump to it from your app...

[KiptonM]

Thanks for the suggestion this is putting me on the right track.

There are 4 different patterns that I can chose from. To keep it simple lets call them ABCD.

The factory default is BOOT_LOCK = 0, nBOOT1 = 1, nBOOT_SEL = 1, and nBOOT0 = 1.

That corresponds to C the third pattern. because Flash Memory is empty, this causes it to go into System memory where the bootloader is. Once it was programmed, because I did not know about the Option Bits I left them at the default, and so it would not let me reprogram it again. Which is what I was seeing.

It appears the only way to make it work is to use B the second configuration. Because I am already bring BOOT0 pin High. It means I have to change nBOOT_SEL from the default of 1 to 0. nBOOT1 bit is already 1, and BOOT_LOCK bit is already 0, And nBOOT0 bit doesn't matter.

Next I have to figure out how to change the bits using the HAL, because unlocking the flash looks complicated.

Thanks for the pointer.

I will post again when it is working.

[istepne]

Hi everyone,

I am also facing the same problem with STM32G031F8P3, TSSOP20 . I have already changed the RESET pin to I/O via option proramming. So, there was no problem with prgramming anymore. And after that I configured the SWD pins as digital ouput I/O on CubeIDE. So, after programming the MCU, I can not connect it any more. Is there a way to recover my MCU. As I understand that, there must be a few seconds before using SWD pins as I/O on startup to make it easy re-programming via SWD port. But now I have to recover my MCU. Is it possible to do that? Or do I have to re-solder and change the MCU?

Regards

Murat

[KiptonM]

What I had to do was make the SWCLK and SWDIO (PA14 and PA13) available to the ST-LINK programmer. In my case PA14 was used for another function so I had to add a 4.7K resistor to that function, and the ST-LINK could over power the other side when it was attached, and the signal could get through if it was not attached.

My reset pin was not an IO but a reset pin. You may have to do the same so the reset pin can be controlled by the ST-LINK

Then the STM32CubeProgrammer can get access to the chip, and change the fuses or reprogram it. I learned this the hard way and made a new version of the board so I could recover if something happened.

[S.Ma]

Low pincount raises the bar for debugging and programming. Reset pin that can turn as IO, boot pin shared with swd signal, swd pins that can too tun as IO.... and FW which can clock stop the core. All this suggest to have a way for the SW to trigger a IO reconfig to programming, a special analog voltage, a long key presssed, a pull up/down at power up on pins, even playing with the time it takes to charge discharge a decohpling cap detect on a slow gpio pin could be considered.... food for thoughts....