(SOLVED) Cannot Upload to STM32F103 "BluePill" using ST Link on Nucleo Board

I have read through so many threads over the last few weeks and have still not been able to resolve this issue.

I am connected to a clone bluepill STM32F103C8 board with 128k using the attached STLINK SWD interface on a Nucleo F411RE development board. I am using 4 lines (3.3v, gnd, SWO, and SWCLK). I read another thread here where the OP had very similar issues to mine and they marked it solved based on wire length, but that is not the issue here. I shortened them to 3 inches and still have the same issue. Again, it works with other methods, just not VSCODE/PLATFORMIO.

Although I can successfully upload to my STM32F103C8 (128k) blue pill clone boards using Arduino IDE v1.88, I cannot using Platformio on VSCODE. I can also successfully communicate with the board using the ST-LINK Utility v4.0.0. I have not tried to upload the firmware using the ST-LINK Utility CLI or the GUI because I do not know how. I will humbly admit that there is a lot I have not looked at and tried, because I do not know where I can find a log of the upload handshake from the Arduino IDE, or what command line parameters to use with the CLI version. I have researched that also, but only today.

If anyone that has solved this can point me in the right direction, I would certainly appreciate it! I want to use VSCODE for ALL my work, and will be happy to put the Arduino IDE behind me. THANKS!

Here is what the ST-LINK Utility says…

16:40:45 : ST-LINK SN : 066CFF545753845187103146
16:40:45 : ST-LINK Firmware version : V2J35M26
16:40:45 : Connected via SWD.
16:40:45 : SWD Frequency = 4,0 MHz.
16:40:45 : Connection mode : Normal.
16:40:45 : Debug in Low Power mode enabled.
16:40:45 : Device ID:0x410 
16:40:45 : Device flash Size : 128KBytes
16:40:45 : Device family :STM32F10xx Medium-density

If someone can direct me to where I can read up on how to get the output from the Arduino IDE then I will be happy to include that here as well.

The code I am uploading is a simple blink program.

#include <Arduino.h>
#define ledPin PC13 //13
void setup()
{
  pinMode(ledPin, OUTPUT);
}
void loop()
{
  digitalWrite(ledPin, HIGH);
  delay(800);
  digitalWrite(ledPin, LOW);
  delay(40);
}

This application works as expected when compiled and uploaded using the Arduino IDE v 1.88. This also compiles without issue in Platformio on VSCode with no issues.

When I try to upload the code in Platformio on VSCode using the icon button (right pointing arrow), this is the output (the tail end of it).

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   4.1% (used 844 bytes from 20480 bytes)
Flash: [==        ]  15.3% (used 10016 bytes from 65536 bytes)
.pio\build\genericSTM32F103C8\firmware.elf  :

section              size        addr
.isr_vector           268   134217728
.text                8792   134217996
.rodata              1088   134226788
.init_array            16   134227876
.fini_array             8   134227892
.data                 136   536870912
.bss                  708   536871048
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29)

.noinit                 0   536871756
Licensed under GNU GPL v2

For bug reports, read
._user_heap_stack    1540   536871756

        http://openocd.org/doc/doxygen/bugs.html
.ARM.attributes        41           0
debug_level: 2


.comment              102           0

hla_swd
.debug_frame         1192           0
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

Total               13891
Info : clock speed 1000 kHz
<lambda>(["upload"], [".pio\build\genericSTM32F103C8\firmware.elf"])
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, serial, stlink
CURRENT: upload_protocol = stlink
Error: open failed
openocd -d2 -s C:\Users\Hop\.platformio\packages\tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "program {.pio\build\genericSTM32F103C8\firmware.elf}  verify reset; shutdown;"
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1
============================================================================================= [FAILED] Took 38.41 seconds =============================================================================================
The terminal process "C:\Users\Hop\.platformio\penv\Scripts\pio.exe 'run', '--verbose', '--target', 'upload', '--environment', 'genericSTM32F103C8'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

EDIT: I forgot to add what my platformio.ini has in it. Here it is.

[env:genericSTM32F103C8]
platform = ststm32
lib_extra_dirs = ~/Documents/Arduino/libraries
board = genericSTM32F103C8
framework = arduino
upload_port = COM4
debug_tool = stlink
upload_protocol = stlink

Your setup works for me, both on Windows and macOS.

The output is slightly different:

Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, serial, stlink
CURRENT: upload_protocol = stlink
Uploading .pio/build/test/firmware.elf
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-12:31)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

hla_swd
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080006b4 msp: 0x20005000
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

Your output additionally includes a dump of the .elf file, is mixed with the output of the OpenOCD output and in particular uses debug level 2 (instead of 1). With the elf dump removed, it looks like so:

xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 2

hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
<lambda>(["upload"], [".pio\build\genericSTM32F103C8\firmware.elf"])
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, serial, stlink
CURRENT: upload_protocol = stlink
Error: open failed
openocd -d2 -s C:\Users\Hop\.platformio\packages\tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "program {.pio\build\genericSTM32F103C8\firmware.elf}  verify reset; shutdown;"
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

Have you made an additional changes you haven’t mentioned? Why is a higher debug level used?

I’ve just spotted this sentence. That’s not correct. It should be:

Signal Pin on Nucleo Pin on Blue Pill
3.3V 1 4
SWCLK 2 2
GND 3 1
SWDIO 4 3

In particular. SWDIO instead of SWO.

1 Like

Close all other programs which use the STLink, like ST-Link utility. I think it just can’t open the adapter.

In addition to what @manuelbl said, make sure that you follow the Nucleo user manual chapter 6.2.4 exactly.

grafik

Doube check pinout and that you removed the two jumpers on CN2, so that the STLink is not connected to the original STM32 MCU on the Nucleo board. (There’s also an “IDD” jumper there, you can pull it out to ensure the lower MCU has no power).

Good Morning Sir, Happy New Year!

I should have been more clear, sorry for the confusion. I was reading off the blue pill pin assignments from the board, and yes I did think that SWO was odd but it appears that is all they had room for. The Nucleo does not have the pin names available on the board. Believe me, I have checked these connections several times against the datasheet, thinking that was the cause, but then remembering that I was successfully able to upload the firmware from the Arduino and the same setup persists as I have not changed anything. I even confirmed what the Arduino IDE already told me by switching the delay values in the program to affect the duty cycle of the blinking LED, so I could visually confirm. Also remember that I can connect with the utility and read the board. This is where I got the output from STLINK to post here.

Also, here is the new verbose output from VSCode/PlatformIO. Thank you for the debug level suggestion!!

[env:genericSTM32F103C8]
platform = ststm32
lib_extra_dirs = ~/Documents/Arduino/libraries
board = genericSTM32F103C8
framework = arduino
upload_port = COM4
debug_tool = stlink
upload_protocol = stlink
build_flags = -DCORE_DEBUG_LEVEL=1

And new verbose output.

> Executing task in folder stm32_rgb: C:\Users\Hop\.platformio\penv\Scripts\pio.exe run --verbose --target upload --environment genericSTM32F103C8 <

Processing genericSTM32F103C8 (platform: ststm32; lib_extra_dirs: ~/Documents/Arduino/libraries; board: genericSTM32F103C8; framework: arduino; upload_port: COM4; debug_tool: stlink; upload_protocol: stlink; build_flags: -DCORE_DEBUG_LEVEL=1)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F103C8.html
PLATFORM: ST STM32 (11.0.0+sha.8416130) (git+https://github.com/platformio/platform-ststm32.git) > STM32F103C8 (20k RAM. 64k Flash)
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash
DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
 - framework-arduinoststm32 4.10900.200819 (1.9.0)
 - framework-cmsis 2.50501.200527 (5.5.1)
 - tool-dfuutil 1.9.200310
 - tool-openocd 2.1000.200630 (10.0)
 - tool-stm32duino 1.0.2
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
MethodWrapper(["checkprogsize"], [".pio\build\genericSTM32F103C8\firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   4.1% (used 844 bytes from 20480 bytes)
Flash: [==        ]  15.3% (used 10016 bytes from 65536 bytes)
.pio\build\genericSTM32F103C8\firmware.elf  :

section              size        addr

.isr_vector           268   134217728

.text                8792   134217996

.rodata              1088   134226788

.init_array            16   134227876

.fini_array             8   134227892

.data                 136   536870912

.bss                  708   536871048

.noinit                 0   536871756

._user_heap_stack    1540   536871756

.ARM.attributes        41           0

.comment              102           0

.debug_frame         1192           0

Total               13891
<lambda>(["upload"], [".pio\build\genericSTM32F103C8\firmware.elf"])
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, serial, stlink
CURRENT: upload_protocol = stlink
openocd -d2 -s C:\Users\Hop\.platformio\packages\tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "program {.pio\build\genericSTM32F103C8\firmware.elf}  verify reset; shutdown;"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 2

hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Error: open failed
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1
============================================================================================== [FAILED] Took 6.51 seconds ==============================================================================================
The terminal process "C:\Users\Hop\.platformio\penv\Scripts\pio.exe 'run', '--verbose', '--target', 'upload', '--environment', 'genericSTM32F103C8'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

Good Morning Sir,

See my reply to manuelbl that replies to your post also, with the additional info that the verbose output I shared was in an environment where I had nothing else running that is related to that COM port, or anything actually except my browser. Also, I have tried to flash unsuccessfully with platformio with NRST connected to the target’s RESET, and not connected. At other times when I was successful (a couple of years ago), I did not connect the NRST then either.

My posted picture shows my jumper settings on the Nucleo. I believe they reflect what you replied with. I believe I got my setup info from the same source because I recognize that info and believe it is in the manual. Thank you for the effort!

@manuelbl and @maxgerhardt, I should have wrapped this all up in one reply. My apologies, I am still learning this environment.

I am just guessing here since I have not used my DSO on this yet. I wonder if the timings are more loosely tolerated using command line parameters from the Arduino IDE than they are from platformio. I know there is some variance in design and quality with these blue pill boards. Unfortunately, the one I am posting about is part of a 50 count batch I bought a couple years ago. Quite a few of them worked fine back then, but I could not for the life of me get them to work as I2C SLAVES, so I mothed-balled their use as I worked with other processors. Now I have another application for them but here I am hitting a brick wall again.

So because these vary so much, I would not know if any specific BUILD-FLAGS would fix this, but I would like to see a variety of those that worked with the STM32F103C8. I cannot seem to find that info anywhere, or how I can see what Arduino IDE uses. I do not know the path used to OpenOCD either and wonder if the versions are different, or the scripts, between VSCODE/PIO and Arduino IDE. I did find a few active instances on a few of my drives.

Thanks for the help and I hope this extra info makes sense to you.

Thank you for your time!

My bluepill board reads “GND”, “CLK”, “IO”, “3.3”, so no SWO here, but GND,SWDCLK,SWDIO,3.3V, as it should be.

When I just tried this setup I might have um… shorted something… because now my VDD_TARGET pin on the SWD header doesn’t give 3.3V anymore. So I plugged it directly into 3.3V in the “Power” section of the Nucleo board.

But this works now.

CURRENT: upload_protocol = stlink
openocd -d2 -s C:\Users\Max\.platformio\packages\tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "program {.pio\build\genericSTM32F103C8\firmware.elf}  verify reset; shutdown;"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 2

hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Info : STLINK V2J34M25 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.253891
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800014c msp: 0x20005000
** Programming Started **
Info : device id = 0x20036410
Info : flash size = 128kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

Can you please open the Windows device manager to check if the there are unknown devices? There should be a line saying

I again highly suspect that there is just a driver issue with something and it cannot recognize your STLink, thus “open” fails in OpenOCD.

You might also need a firmware upgrade of the STLink, downlodable from STSW-LINK007 - ST-LINK, ST-LINK/V2, ST-LINK/V2-1, STLINK-V3 boards firmware upgrade - STMicroelectronics.

Thank you for that info. I am also powering my STM32 from the lower half of the Nucleo. That target power is a reporting pin (I thought) to report if the target has power before proceeding. Someone told me it was a high-impedance switchable port but I never checked the schematic to confirm. I believe I did test it with my DMM once though and got the same results as you.

I am curious, isn’t OpenOCD used by Arduino IDE? There is a file size and date difference between the two instances of OpenOCD.EXE I found.

Are you using anything special in your platformio.ini file? I would love to see what you have in there. I remember something about build-flags that fixed this for me last time, but I cannot find that info anywhere!!

My ST-LINK appears to be functioning normally with the latest driver.

Serial Driver

I used the same as yours (with commented out extra dirs)

[env:genericSTM32F103C8]
platform = ststm32
;lib_extra_dirs = ~/Documents/Arduino/libraries
board = genericSTM32F103C8
framework = arduino
upload_port = COM4
debug_tool = stlink
upload_protocol = stlink
build_flags = -DCORE_DEBUG_LEVEL=1

though it must be said that upload_port = COM4 makes no sense since it uploads via the USB device of an STLink, that is ignored. Only when doing serial uploads, that would matter.

Can you try the firmware upgrade program and see if that makes a difference?

After that you can also try and change

upload_protocol = stlink

to

upload_protocol = mbed

on “This computer” there should be a “NODE_F411RE” virutal USB drive. That is opened by the STLink and accepts copying a firmware.bin file to it, that the Nucleo then tries to flash to the board. Usually done for mbed boards, but works on Nucleo boards, too. If that doesn’t work either, something is wrong with the STLink.

@hop Thanks for the image. I spot two problems:

  • The boards are incorrectly wired. On the Nucelo SWD connector, pins 1 – 4 should be connected, not 2 – 5.
  • The Blue Pill should have an independent power supply, either via USB or some other 3.3V source.

VDD_TARGET is mainly used to measure the voltage of the target, not to deliver power. Some ST-Links can provide power as well but I’m not sure about the Nucelo’s ST-Link.

OK, I know I tried MBED before because I have it commented out in the ini file, so I changed it back, and now I am showing that the firmware.bin file is not found. The output is below.

By the way, I did drag the firmware.bin file over to the NODE_F411RE drive and it flashed just fine. The ONLY issue I had was that I had to press the reset button for it to run, and I cannot find an option to fix that like you can with the automatic mode dialog window in the utility.

Here is the verbose output (MBED UPLOAD). I would imagine that not being able to find the firmware bin file would be a real deal breaker. I wonder why, and where I can repair that.

> Executing task in folder stm32_rgb: C:\Users\Hop\.platformio\penv\Scripts\pio.exe run --verbose --target upload --environment genericSTM32F103C8 <

Processing genericSTM32F103C8 (platform: ststm32; lib_extra_dirs: ~/Documents/Arduino/libraries; board: genericSTM32F103C8; framework: arduino; upload_port: COM4; debug_tool: stlink; upload_protocol: mbed; build_flags: -DCORE_DEBUG_LEVEL=1)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F103C8.html
PLATFORM: ST STM32 (11.0.0+sha.8416130) (git+https://github.com/platformio/platform-ststm32.git) > STM32F103C8 (20k RAM. 64k Flash)
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash
DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES: 
 - framework-arduinoststm32 4.10900.200819 (1.9.0)
 - framework-cmsis 2.50501.200527 (5.5.1)
 - tool-dfuutil 1.9.200310
 - tool-openocd 2.1000.200630 (10.0)
 - tool-stm32duino 1.0.2
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
MethodWrapper(["checkprogsize"], [".pio\build\genericSTM32F103C8\firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   4.1% (used 844 bytes from 20480 bytes)
Flash: [==        ]  15.3% (used 10016 bytes from 65536 bytes)
.pio\build\genericSTM32F103C8\firmware.elf  :
*** [upload] COM4\firmware.bin: No such file or directory

section              size        addr

.isr_vector           268   134217728

.text                8792   134217996

.rodata              1088   134226788

.init_array            16   134227876

.fini_array             8   134227892

.data                 136   536870912

.bss                  708   536871048

.noinit                 0   536871756

._user_heap_stack    1540   536871756

.ARM.attributes        41           0

.comment              102           0

.debug_frame         1192           0

Total               13891
<lambda>(["upload"], [".pio\build\genericSTM32F103C8\firmware.bin"])
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, mbed, serial, stlink
CURRENT: upload_protocol = mbed
MethodWrapper(["upload"], [".pio\build\genericSTM32F103C8\firmware.bin"])
Use manually specified: COM4
MethodWrapper(["upload"], [".pio\build\genericSTM32F103C8\firmware.bin"])
============================================================================================== [FAILED] Took 5.90 seconds ==============================================================================================
The terminal process "C:\Users\Hop\.platformio\penv\Scripts\pio.exe 'run', '--verbose', '--target', 'upload', '--environment', 'genericSTM32F103C8'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

This is what I have for the SWD on the Nucleo. As far as I can see, it is also the same on the discovery. The first pin is the VDD_TARGET like you mentioned and is not used. So I am using 2-4. Pin 5 is connected (NRST) with a jumper but is NOT used and not connected to RESET on the STM32F103. 2 is SW Clock, 3 is GND, and 4 is SW DIO. Besides, it has to be hooked up correctly because I use to be able to connect, a couple of years ago, and I reconnected this based on images and data from that time period. Also, Arduino IDE and STLINK are able to upload without issue, which would not work if my connections were incorrect. UNLESS for some reason, the command line arguments from OpenOCD include using VDD_TARGET to confirm connection. Hmm.

EDIT: And I have always used the 3.3v on the F411RE board for power. I am not sure why it is not available on the SWD port. Maybe it is not a best practice to use the power from the NUCLEO attached target board. I have never had any problems though. Usually, when I have other devices connected, I already have a power bus set up, instead of just powering the target.

You are correct. By looking at the connectors on both boards, I’ve counted 4 wires. But there are 5. And with your description, I also understand where the brown one goes.

@maxgerhardt, @manuelbl I GOT IT!!! YAY!
Thank you max for the nudge in the right direction. Indeed, upload_port was not needed, and when I commented it out, the upload worked! I looked over the last failed verbose output and noticed that the path of the firmware that was not found was COM4/firmware.bin. This is really odd actually that the firmware would be expected at a subdirectory of COM4 just because a com port was used. Weird. I am sure there is a reason.

Anyway, the only issue I have now is that the board does not auto reset. Perhaps the use of the NRST line might be for this purpose. Checking…

And indeed it is!! I will have to use my scope to see if there is a pulse on that line, but after I wired it up, the application ran as if I did a hard reset. Now that is TWO long-term issues solved.

Thank you gentlemen for your help and suggestions, I appreciate it!!

EDIT: [after-thought] - Also, Max, I appreciate the tip about the MBED drive and dragging code over to it. I would imagine that the same result would occur if a firmware file was copied to that path via a script. That would almost completely negate the need to jump through all those hoops with OpenOCD! I wonder if I can set PIO to just run a script and copy that file over when I wish to upload. I’ll have to explore that someday.

This happened because when using upload_protocol = mbed, then upload_port is respected, as the path you want to copy the firmware too. If you’d want to do this manually you’d say upload_port = E:, for example.

It’s good that that upload method is working now, but then the OpenOCD upload is still not working? Without that, you also cannot use debugging, as that requires the SWD interface.

Have you tried the firmware upgrade of the STLink already? LINK Firmware version : V2J35M26 is two majors behind the current

Maybe also uninstall the driver in the Windows device manager and install them again using the latest version found in ST-Link utility (C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK_USB_V2_1_Driver)

@maxgerhardt Out of curiousity, that image you shared that is your version… yours was out of date also? Or am I reading that wrong? V2J34M25… mine is V2J35M26 (newer?) and the current one is V2J37M26 (newest?). I just want to make sure I got that straight. So technically, if I also had your version then it would also work? This would indicate that there is just a problem with my version, which correct, is out of date. So… just saying, if the current version does not work also, and this is the issue, then I could roll back to your V2J34M25 and it should work. Again, if the ST-LINK version is the issue. Right?

I’m on it. Thank you sir. And PLEASE correct me if I am missing something.

Yes my initial one was older than yours, but for me it worked with that older and also the newest version. So if you upgrade to the newest version as well there’s no version difference between us, and if it still fails, it must be something else.

In that case I’d ask you to open a PlatformIO CLI and execute

C:\Users\Hop\.platformio\packages\tool-openocd\bin\openocd -d3 -s C:\Users\Hop\.platformio\packages\tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "program {.pio\build\genericSTM32F103C8\firmware.elf}  verify reset; shutdown;"

That is the maximum debug output and should hopefully reveal something.

[quote=“maxgerhardt, post:18, topic:18180”]
C:\Users\Hop\.platformio\tool-openocd\bin\openocd -d3 -s C:\Users\Hop\.platformio\packages\tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "program {.pio\build\genericSTM32F103C8\firmware.elf} verify reset; shutdown;"
[/quote

I ran what you posted but I got an error and that path “C:\Users\Hop.platformio\tool-openocd\bin\openocd” does not exist on my system. I instead tried to run it with “\packages” added and the output is below. If I am suppose to have a “C:\Users\Hop.platformio\tool-openocd\bin” folder in addition to and looks like “C:\Users\Hop.platformio\packages\tool-openocd\bin” then there might be the problem. I just figured you forgot "\packages\ in your path, after .platformio.

PS O:\code\platformio\stm32_rgb> C:\Users\Hop\.platformio\packages\tool-openocd\bin\openocd -d3 -s C:\Users\Hop\.platformio\packages\tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "program {.pio\build\genericSTM32F103C8\firmware.elf}  verify reset; shutdown;"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
User : 13 4 options.c:63 configuration_output_handler(): debug_level: 3
User : 14 10 options.c:63 configuration_output_handler(): 
Debug: 15 20 configuration.c:42 add_script_search_dir(): adding C:\Users\Hop\.platformio\packages\tool-openocd/scripts
Debug: 16 31 options.c:187 add_default_dirs(): bindir=bin
Debug: 17 57 options.c:188 add_default_dirs(): pkgdatadir=
Debug: 18 63 options.c:189 add_default_dirs(): exepath=C:/Users/Hop/.platformio/packages/tool-openocd/bin
Debug: 19 122 options.c:190 add_default_dirs(): bin2data=../
Debug: 20 128 configuration.c:42 add_script_search_dir(): adding C:\Users\Hop\AppData\Roaming/OpenOCD
Debug: 21 164 configuration.c:42 add_script_search_dir(): adding C:/Users/Hop/.platformio/packages/tool-openocd/bin/..//site
Debug: 22 196 configuration.c:42 add_script_search_dir(): adding C:/Users/Hop/.platformio/packages/tool-openocd/bin/..//scripts
Debug: 23 257 configuration.c:97 find_file(): found C:\Users\Hop\.platformio\packages\tool-openocd/scripts/interface/stlink.cfg
Debug: 24 294 command.c:146 script_debug(): command - adapter driver hla
Debug: 26 303 command.c:352 register_command_handler(): registering 'hla_device_desc'...
Debug: 27 310 command.c:352 register_command_handler(): registering 'hla_serial'...
Debug: 28 339 command.c:352 register_command_handler(): registering 'hla_layout'...
Debug: 29 347 command.c:352 register_command_handler(): registering 'hla_vid_pid'...
Debug: 30 378 command.c:352 register_command_handler(): registering 'hla_command'...
Debug: 31 410 command.c:146 script_debug(): command - hla_layout stlink
Debug: 33 443 hla_interface.c:242 hl_interface_handle_layout_command(): hl_interface_handle_layout_command
Debug: 34 476 command.c:146 script_debug(): command - hla_device_desc ST-LINK
Debug: 37 506 hla_interface.c:216 hl_interface_handle_device_desc_command(): hl_interface_handle_device_desc_command
Debug: 38 540 command.c:146 script_debug(): command - hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753
Debug: 40 555 command.c:146 script_debug(): command - transport select hla_swd
Debug: 41 561 hla_transport.c:189 hl_transport_select(): hl_transport_select
Debug: 42 595 command.c:352 register_command_handler(): registering 'hla'...
Debug: 43 630 command.c:352 register_command_handler(): registering 'jtag'...
Debug: 44 731 command.c:352 register_command_handler(): registering 'jtag'...
Debug: 45 739 command.c:352 register_command_handler(): registering 'jtag'...
Debug: 46 745 command.c:352 register_command_handler(): registering 'jtag'...
Debug: 47 781 command.c:352 register_command_handler(): registering 'jtag'...
Debug: 48 813 command.c:352 register_command_handler(): registering 'jtag'...
Debug: 49 844 command.c:352 register_command_handler(): registering 'jtag'...
Debug: 50 874 command.c:352 register_command_handler(): registering 'jtag'...
Debug: 51 882 command.c:352 register_command_handler(): registering 'jtag'...
Debug: 52 913 command.c:352 register_command_handler(): registering 'jtag_ntrst_delay'...
User : 53 949 options.c:63 configuration_output_handler(): hla_swdUser : 54 979 options.c:63 configuration_output_handler(): 
Debug: 55 1010 configuration.c:97 find_file(): found C:\Users\Hop\.platformio\packages\tool-openocd/scripts/target/stm32f1x.cfg
Debug: 56 1049 configuration.c:97 find_file(): found C:\Users\Hop\.platformio\packages\tool-openocd/scripts/target/swj-dp.tcl
Debug: 57 1060 command.c:146 script_debug(): command - transport select
Debug: 58 1066 configuration.c:97 find_file(): found C:\Users\Hop\.platformio\packages\tool-openocd/scripts/mem_helper.tcl
Debug: 59 1128 command.c:146 script_debug(): command - add_usage_text mrw address
Debug: 62 1161 command.c:1123 help_add_command(): added 'mrw' help text
Debug: 63 1193 command.c:146 script_debug(): command - add_help_text mrw Returns value of word in memory.
Debug: 65 1227 command.c:1136 help_add_command(): added 'mrw' help text
Debug: 66 1235 command.c:146 script_debug(): command - add_usage_text mrh address
Debug: 68 1243 command.c:1123 help_add_command(): added 'mrh' help text
Debug: 69 1249 command.c:146 script_debug(): command - add_help_text mrh Returns value of halfword in memory.
Debug: 71 1310 command.c:1136 help_add_command(): added 'mrh' help text
Debug: 72 1343 command.c:146 script_debug(): command - add_usage_text mrb address
Debug: 74 1350 command.c:1123 help_add_command(): added 'mrb' help text
Debug: 75 1379 command.c:146 script_debug(): command - add_help_text mrb Returns value of byte in memory.
Debug: 77 1414 command.c:1136 help_add_command(): added 'mrb' help text
Debug: 78 1445 command.c:146 script_debug(): command - add_usage_text mmw address setbits clearbits
Debug: 80 1479 command.c:1123 help_add_command(): added 'mmw' help text
Debug: 81 1511 command.c:146 script_debug(): command - add_help_text mmw Modify word in memory. new_val = (old_val & ~clearbits) | setbits;
Debug: 83 1546 command.c:1136 help_add_command(): added 'mmw' help text
Debug: 84 1583 command.c:146 script_debug(): command - transport select
Debug: 85 1616 command.c:146 script_debug(): command - transport select
Debug: 86 1648 command.c:146 script_debug(): command - transport select
Debug: 87 1677 command.c:146 script_debug(): command - transport select
Debug: 88 1683 command.c:146 script_debug(): command - hla newtap stm32f1x cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x1ba01477
Debug: 89 1744 hla_tcl.c:110 jim_hl_newtap_cmd(): Creating New Tap, Chip: stm32f1x, Tap: cpu, Dotted: stm32f1x.cpu, 8 params
Debug: 90 1758 hla_tcl.c:121 jim_hl_newtap_cmd(): Processing option: -irlen
Debug: 91 1764 hla_tcl.c:121 jim_hl_newtap_cmd(): Processing option: -ircapture
Debug: 92 1793 hla_tcl.c:121 jim_hl_newtap_cmd(): Processing option: -irmask
Debug: 93 1799 hla_tcl.c:121 jim_hl_newtap_cmd(): Processing option: -expected-id
Debug: 94 1831 core.c:1484 jtag_tap_init(): Created Tap: stm32f1x.cpu @ abs position 0, irlen 0, capture: 0x0 mask: 0x0
Debug: 95 1859 command.c:146 script_debug(): command - dap create stm32f1x.dap -chain-position stm32f1x.cpu
Debug: 96 1868 command.c:146 script_debug(): command - transport select
Debug: 97 1899 command.c:146 script_debug(): command - target create stm32f1x.cpu cortex_m -endian little -dap stm32f1x.dap
Info : 98 1934 target.c:5439 target_create(): The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Debug: 99 2000 hla_target.c:369 adapter_target_create(): adapter_target_create
Debug: 100 2009 hla_target.c:339 adapter_init_arch_info(): adapter_init_arch_info
Debug: 101 2017 command.c:352 register_command_handler(): registering 'arm'...
Debug: 102 2046 command.c:352 register_command_handler(): registering 'arm'...
Debug: 103 2077 command.c:352 register_command_handler(): registering 'arm'...
Debug: 104 2084 command.c:352 register_command_handler(): registering 'arm'...
Debug: 105 2115 command.c:352 register_command_handler(): registering 'arm'...
Debug: 106 2148 command.c:352 register_command_handler(): registering 'arm'...
Debug: 107 2179 command.c:352 register_command_handler(): registering 'arm'...
Debug: 108 2212 command.c:352 register_command_handler(): registering 'arm'...
Debug: 109 2244 command.c:352 register_command_handler(): registering 'arm'...
Debug: 110 2251 command.c:352 register_command_handler(): registering 'tpiu'...
Debug: 111 2284 command.c:352 register_command_handler(): registering 'itm'...
Debug: 112 2349 command.c:352 register_command_handler(): registering 'itm'...
Debug: 113 2403 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 114 2450 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 115 2465 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 116 2524 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 117 2533 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 118 2562 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 119 2569 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 120 2602 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 121 2663 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 122 2695 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 123 2703 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 124 2734 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 125 2766 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 126 2795 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 127 2803 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 128 2834 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 129 2868 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 130 2899 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 131 2932 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 132 2965 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 133 2997 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 134 3032 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 135 3064 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 136 3096 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 137 3129 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 138 3136 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 139 3170 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 140 3204 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 141 3236 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 142 3298 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 143 3331 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 144 3363 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 145 3370 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 146 3404 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 147 3437 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 148 3471 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 149 3502 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 150 3537 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...
Debug: 151 3573 command.c:146 script_debug(): command - stm32f1x.cpu configure -work-area-phys 0x20000000 -work-area-size 0x1000 -work-area-backup 0
Debug: 152 3585 target.c:1978 target_free_all_working_areas_restore(): freeing all working areas
Debug: 153 3617 target.c:1978 target_free_all_working_areas_restore(): freeing all working areas
Debug: 154 3661 target.c:1978 target_free_all_working_areas_restore(): freeing all working areas
Debug: 155 3704 command.c:146 script_debug(): command - flash bank stm32f1x.flash stm32f1x 0x08000000 0 0 0 stm32f1x.cpu
Debug: 156 3715 log.c:419 gdb_timeout_warning(): keep_alive() was not invoked in the 1000 ms timelimit (2554 ms). This may cause trouble with GDB connections.
Debug: 159 3783 command.c:352 register_command_handler(): registering 'stm32f1x'...
Debug: 160 3819 command.c:352 register_command_handler(): registering 'stm32f1x'...
Debug: 161 3849 command.c:352 register_command_handler(): registering 'stm32f1x'...
Debug: 162 3882 command.c:352 register_command_handler(): registering 'stm32f1x'...
Debug: 163 3889 command.c:352 register_command_handler(): registering 'stm32f1x'...
Debug: 164 3973 command.c:352 register_command_handler(): registering 'stm32f1x'...
Debug: 165 3995 tcl.c:1261 handle_flash_bank_command(): 'stm32f1x' driver usage field missing
Debug: 166 4003 command.c:146 script_debug(): command - adapter speed 1000
Debug: 168 4067 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 169 4073 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 170 4134 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 171 4166 command.c:146 script_debug(): command - adapter srst delay 100
Debug: 173 4199 command.c:146 script_debug(): command - transport select
Debug: 174 4205 command.c:146 script_debug(): command - reset_config srst_nogate
Debug: 177 4237 command.c:146 script_debug(): command - transport select
Debug: 178 4275 command.c:146 script_debug(): command - stm32f1x.cpu configure -event examine-end 
        # DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP |
        #              DBG_STANDBY | DBG_STOP | DBG_SLEEP
        mmw 0xE0042004 0x00000307 0

Debug: 179 4320 command.c:146 script_debug(): command - stm32f1x.cpu configure -event trace-config 
        # Set TRACE_IOEN; TRACE_MODE is set to async; when using sync
        # change this value accordingly to configure trace pins
        # assignment
        mmw 0xE0042004 0x00000020 0

Debug: 180 4387 command.c:146 script_debug(): command - init
Debug: 182 4413 command.c:146 script_debug(): command - target init
Debug: 184 4418 command.c:146 script_debug(): command - target names
Debug: 185 4444 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-erase-start
Debug: 186 4452 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-erase-start reset init
Debug: 187 4480 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-write-end
Debug: 188 4488 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-write-end reset halt
Debug: 189 4516 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-attach
Debug: 190 4523 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-attach halt
Debug: 191 4548 target.c:1440 handle_target_init_command(): Initializing targets...
Debug: 192 4555 hla_target.c:359 adapter_init_target(): adapter_init_target
Debug: 193 4579 semihosting_common.c:97 semihosting_common_init():  
Debug: 194 4585 command.c:352 register_command_handler(): registering 'target_request'...
Debug: 195 4634 command.c:352 register_command_handler(): registering 'trace'...
Debug: 196 4664 command.c:352 register_command_handler(): registering 'trace'...
Debug: 197 4671 command.c:352 register_command_handler(): registering 'fast_load_image'...
Debug: 198 4718 command.c:352 register_command_handler(): registering 'fast_load'...
Debug: 199 4748 command.c:352 register_command_handler(): registering 'profile'...
Debug: 200 4755 command.c:352 register_command_handler(): registering 'virt2phys'...
Debug: 201 4785 command.c:352 register_command_handler(): registering 'reg'...
Debug: 202 4815 command.c:352 register_command_handler(): registering 'poll'...
Debug: 203 4821 command.c:352 register_command_handler(): registering 'wait_halt'...
Debug: 204 4853 command.c:352 register_command_handler(): registering 'halt'...
Debug: 205 4892 command.c:352 register_command_handler(): registering 'resume'...
Debug: 206 4901 command.c:352 register_command_handler(): registering 'reset'...
Debug: 207 4939 command.c:352 register_command_handler(): registering 'soft_reset_halt'...
Debug: 208 4968 command.c:352 register_command_handler(): registering 'step'...
Debug: 209 4998 command.c:352 register_command_handler(): registering 'mdd'...
Debug: 210 5005 command.c:352 register_command_handler(): registering 'mdw'...
Debug: 211 5034 command.c:352 register_command_handler(): registering 'mdh'...
Debug: 212 5041 command.c:352 register_command_handler(): registering 'mdb'...
Debug: 213 5071 command.c:352 register_command_handler(): registering 'mwd'...
Debug: 214 5103 command.c:352 register_command_handler(): registering 'mww'...
Debug: 215 5133 command.c:352 register_command_handler(): registering 'mwh'...
Debug: 216 5140 command.c:352 register_command_handler(): registering 'mwb'...
Debug: 217 5171 command.c:352 register_command_handler(): registering 'bp'...
Debug: 218 5202 command.c:352 register_command_handler(): registering 'rbp'...
Debug: 219 5233 command.c:352 register_command_handler(): registering 'wp'...
Debug: 220 5240 command.c:352 register_command_handler(): registering 'rwp'...
Debug: 221 5271 command.c:352 register_command_handler(): registering 'load_image'...
Debug: 222 5300 command.c:352 register_command_handler(): registering 'dump_image'...
Debug: 223 5307 command.c:352 register_command_handler(): registering 'verify_image_checksum'...
Debug: 224 5399 command.c:352 register_command_handler(): registering 'verify_image'...
Debug: 225 5406 command.c:352 register_command_handler(): registering 'test_image'...
Debug: 226 5435 command.c:352 register_command_handler(): registering 'reset_nag'...
Debug: 227 5465 command.c:352 register_command_handler(): registering 'ps'...
Debug: 228 5472 command.c:352 register_command_handler(): registering 'test_mem_access'...
Debug: 229 5501 hla_interface.c:109 hl_interface_init(): hl_interface_init
Debug: 230 5507 hla_layout.c:83 hl_layout_init(): hl_layout_init
Debug: 231 5538 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 232 5569 core.c:1789 adapter_khz_to_speed(): have interface set up
Debug: 233 5575 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 234 5601 core.c:1789 adapter_khz_to_speed(): have interface set up
Info : 235 5607 core.c:1565 adapter_init(): clock speed 1000 kHz
Debug: 236 5640 openocd.c:157 handle_init_command(): Debug Adapter init complete
Debug: 237 5675 command.c:146 script_debug(): command - transport init
Debug: 238 5703 log.c:419 gdb_timeout_warning(): keep_alive() was not invoked in the 1000 ms timelimit (1466 ms). This may cause trouble with GDB connections.
Debug: 241 5768 transport.c:239 handle_transport_init(): handle_transport_init
Debug: 242 5775 hla_transport.c:152 hl_transport_init(): hl_transport_init
Debug: 243 5807 hla_transport.c:169 hl_transport_init(): current transport hla_swd
Debug: 244 5837 hla_interface.c:42 hl_interface_open(): hl_interface_open
Debug: 245 5869 hla_layout.c:40 hl_layout_open(): hl_layout_open
Debug: 246 5874 stlink_usb.c:2797 stlink_usb_open(): stlink_usb_open
Debug: 247 5905 stlink_usb.c:2809 stlink_usb_open(): transport: 4 vid: 0x0483 pid: 0x3744 serial:
Debug: 248 5937 stlink_usb.c:2809 stlink_usb_open(): transport: 4 vid: 0x0483 pid: 0x3748 serial:
Debug: 249 5968 stlink_usb.c:2809 stlink_usb_open(): transport: 4 vid: 0x0483 pid: 0x374b serial:
Debug: 250 5999 stlink_usb.c:2809 stlink_usb_open(): transport: 4 vid: 0x0483 pid: 0x374d serial:
Debug: 251 6008 stlink_usb.c:2809 stlink_usb_open(): transport: 4 vid: 0x0483 pid: 0x374e serial:
Debug: 252 6034 stlink_usb.c:2809 stlink_usb_open(): transport: 4 vid: 0x0483 pid: 0x374f serial:
Debug: 253 6070 stlink_usb.c:2809 stlink_usb_open(): transport: 4 vid: 0x0483 pid: 0x3752 serial:
Debug: 254 6101 stlink_usb.c:2809 stlink_usb_open(): transport: 4 vid: 0x0483 pid: 0x3753 serial:
Error: 255 6169 stlink_usb.c:2826 stlink_usb_open(): open failed
Debug: 256 6174 hla_layout.c:47 hl_layout_open(): failed
Debug: 257 6181 command.c:626 run_command(): Command 'transport init' failed with error code -4
User : 258 6188 command.c:692 command_run_line(): in procedure 'program'
Debug: 259 6218 command.c:626 run_command(): Command 'init' failed with error code -4
Debug: 260 6225 command.c:146 script_debug(): command - echo ** OpenOCD init failed **
User : 263 6258 command.c:767 jim_echo(): ** OpenOCD init failed **
Debug: 264 6289 command.c:146 script_debug(): command - shutdown error
User : 266 6318 server.c:755 handle_shutdown_command(): shutdown command invoked
Debug: 267 6325 command.c:626 run_command(): Command 'shutdown' failed with error code -4
User : 268 6356 command.c:692 command_run_line():
Debug: 269 6386 target.c:1978 target_free_all_working_areas_restore(): freeing all working areas
Debug: 270 6417 hla_interface.c:117 hl_interface_quit(): hl_interface_quit
PS O:\code\platformio\stm32_rgb>
1 Like

OpenOCD cannot find a USB device of the specified vendor and product ID pair.

What does the Windows device manager say about the PID and VID of the “ST-Link debug” device?
grafik

For me VID=0x0483 and PID=0x374B exist, so it would find it in the third entry.