Problems uploading a second time with StLink

Hello Guys,

just to let you know, I am a first time user of PlatformIO inside Visual Code Studio, before i only used Arduino together with SMT32duino to program STM32 boards.

I currently have a problem with uploading to a STM32G071GBU6N.


platform = ststm32
framework = arduino
board = Generic_G071GBUxN
lib_archive = false
upload_protocol = stlink

debug_tool = stlink
debug_port =

board_build.ldscript = ./boards/ldscript.ld

Error message:

xPack Open On-Chip Debugger 0.12.0-01004-g9ea7f3d64-dirty (2023-01-30-15:04)
Licensed under GNU GPL v2
For bug reports, read
debug_level: 1

Error: init mode failed (unable to connect to the target)
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1

What did i try:

  • uploading to the STM with a StLink programmer included in a Nucelo board

What did i do:

  • Install newest STM32CubeProgrammer tool includijng drivers
  • make a custom board definition to program the unsupported board
  • try different debug_ports and tools

First of all It works flawlessly in Arduino and in STM32CubeProgrammer. I can connect to the G071 without problems, can erase and program it.

Second: it also works with:


upload_protocol = mbed

So i am very certain that the connections are correct.

Third: It also works the first time.

I can erase the chip with STM32CubeProgrammer and than get a single chance to upload with PlatformIO. The upload “fails” with the same “Error 1” but actually uploads the code.
After that I only get the above error message and cant reupload.

I have read that this might be an issue regarding post upload debug connection which cant be established, so in tried some random debug settings but nothing works.

What i want to to:

  • upload with STLink and upload_protocol = stlink for faster uploads
  • debug with STLink

Any suggestions how i can do that/what i am doing wrong?
I also have no idea how to get debugging working.

I am on Windows 11 BTW.

Just to have everything in one post, here is the custom board definition which might also be wrong?

    "build": {
      "core": "stm32",
      "cpu": "cortex-m0plus",
      "extra_flags": "-DSTM32G0xx -DSTM32G071xx",
      "f_cpu": "64000000L",
      "framework_extra_flags": {
        "arduino": "-D__CORTEX_SC=0 -DARDUINO_GENERIC_G071GBUXN"
      "mcu": "stm32g071gbuxn",
      "product_line": "STM32G071xx",
      "variant": "STM32G0xx/G071G(8-B)UxN_G081GBUxN"
    "debug": {
      "default_tools": [
      "jlink_device": "STM32G071GBUxN",
      "onboard_tools": [
      "openocd_target": "stm32g0x",
      "svd_path": "STM32G071.svd"
    "frameworks": [
    "name": "Generic_G071GBUXN",
    "upload": {
      "maximum_ram_size": 36864,
      "maximum_size": 131072,
      "protocol": "stlink",
      "protocols": [
    "url": "",
    "vendor": "ST"
  1. What code are you running as src/main.cpp? Must be careful not to use the SWDIO or SWCLK pins as GPIO
  2. Are you connecting the reset pin between the ST-Link and the STM32G0?
  3. When you use the STM32CubeProgrammer, what setting do you use for “Reset Mode” when connecting to the chip?
1 Like

Ah ok, that makes sense. I use SWDIO as a SPI CS (software controlled) pin.

NRST is connected.

Reset mode was set to hardware, Software didnt work…

I am just silly for using the SWDIO pin as a GPIO so no debugging for me.

Is there still a way to upload using stlink?
The mbed method seems unrelaible as it sometimes fails and than cant reflash because “no space left on device” - so i need to delete the usb drive myself.

Then maybe the default reset method used in the stm32g0x.cfg is “software reset”, i.e., trying to do a reset by sending a command via SWDIO+SWCLK. Since you use one of those as I/O, that fails. When it instead does a hardware reset via NRST before that, or during that, it’s able to use SWD again.

There are a lot more reset methods available.

A quick thing to try would be to use the config aimed at a Nucleo G0 (st_nucleo_g0.cfg): The config is generic for all G0x boards and uses the reset_config srst_only method, which may be the one you need.

Just replace


      "openocd_board": "st_nucleo_g0",

(see platform code).

Otherwise, use your original config, find the stm32g0x.cfg file in C:\Users\<user>\.platformoi\packages\tool-openocd\ and play around with all possibly reset configs and see which ones work.

1 Like

Looks like that isnt the issue.

  "openocd_board": "st_nucleo_g0",

dosnt work.

I tried and both

 reset_config srst_only srst_nogate connect_assert_srst
 reset_config trst_and_srst srst_nogate connect_assert_srst

work (as in uploads) but still fail with the same “[upload] Error 1”.

Wouldnt changing the stm32g0x.cfg file be bad practice as its not included in the project?
How can i pass that reset_config to openocd without changing the file?

I have read somewhere that the upload error coud be because openocd waits on the debug target to appear which it doesnt in my case.
Maybe i need to disable debugging somehow to not have that Error 1?

Absolutely, it’s bad practice as a permanent fix but perfect for a temporary experimentation. You can affect upload flags with e.g. upload_flags = -c "reset_config ..." in the platformio.ini, or with a script.

Very interesting. Can you counteract that in your application by adding a startup delay before you reconfigure the pin to be an GPIO pin instead of SWDIO/SWCL?

Looks like a delay makes it behave.


I need just over 150ms to make it relaibly not show the error message.

I set the upload flag to:

upload_flags = -c "reset_config" "srst_only" "srst_nogate" "connect_assert_srst"

That works.

Thank you very much!

Interestingly, i cant get debug working with that upload flag.

I always get that even though i deactivated the SWDIO GPIO reuse and delay.

After you’ve done that, does uploading work without upload_flags, or does it still need it?