Cannot upload to STM32 Bluepill board over STLink-V2

I want to program my bluepill board using a STLink-V2 debug probe (clone).

I have upgraded PIO to the latest version and updated all platform files.

$ pio --version
PlatformIO, version 3.5.2b5
$ pio platform update
Updating tool-scons                      @ 2.20501.3      [Up-to-date]
Updating tool-unity                      @ 1.20302.1      [Up-to-date]
Updating contrib-pysite                  @ 0.1.5          [Up-to-date]
Updating tool-pioplus                    @ 0.14.1         [Up-to-date]

Platform Manager
Platform ST STM32
Updating ststm32                         @ 4.0.0          [Up-to-date]
Updating tool-stm32duino                 @ 1.0.0          [Up-to-date]
Updating framework-arduinoststm32        @ 2.1.180219     [Up-to-date]
Updating toolchain-gccarmnoneeabi        @ 1.70201.0      [Up-to-date]
Updating tool-stlink                     @ 1.10400.0      [Up-to-date]

When I create a new project using pio init -b bluepill_f103c8 --ide=eclipse and add the basic blink sketch, it compiles fine.


platform = ststm32
board = bluepill_f103c8
framework = arduino

At uploading however it fails to find openocd.

$ pio run -t upload

Checking program size
text	   data	    bss	    dec	    hex	filename
6472	   1944	    344	   8760	   2238	.pioenvs\bluepill_f103c8\firmware.elf
Configuring upload protocol...
AVAILABLE: blackmagic, jlink, mbed, stlink, stlink
CURRENT: upload_protocol = stlink
openocd -s -f scripts/interface/stlink.cfg -c "transport select hla_swd" -f scripts/target/stm32f1x.cfg -c "program {{.pioenvs\bluepill_f103c8\firmware.elf}}  verify reset; shutdown;"
The command "openocd" is either written incorrcetly or couldn't be found. [translated message]
*** [upload] Error 1

When I look at my .platformio/packages/ folder, I don’t see a tools-openocd folder in which there might be openocd.exe.

Also, even if openocd would be found in the path, it still selects the wrong file. There is no stlink.cfg in the interface/ folder (here). I would need it to select the stlink-v2.cfg file.

I can however flash the produced firmware using the STM32 ST-LINK Utility just fine, and the firmware works perfectly.

19:23:03 : ST-LINK SN : Old ST-LINK firmware/ST-LINK already used
19:23:03 : ST-LINK Firmware version : V2J17S4 (Need Update)
19:23:03 : Old ST-LINK firmware detected!
                  Please upgrade it from ST-LINK->'Firmware update' menu.
19:23:03 : Connected via SWD.
19:23:03 : Connection mode : Connect Under Reset.
19:23:03 : Debug in Low Power mode enabled.
19:23:03 : Device ID:0x410 
19:23:03 : Device flash Size : 128KBytes
19:23:03 : Device family :STM32F10xx Medium-density
19:23:27 : [firmware.bin] opened successfully.
19:23:27 : [firmware.bin] checksum : 0x001060C5 
19:23:53 : Memory programmed in 3s and 438ms.
19:23:53 : Verification...OK
19:23:53 : Programmed memory Checksum: 0x001060C5

So this shouldn’t be problem with my STLinkV2 clone.

What am I doing wrong, how can I flash my Bluepill using ST-Link V2 over SWD?

I’ve just fixed that. Could you re-test with upstream version?

If it works, I’ll make a quick release.

I re-tested and it flashes the new firmware now correctly, although it exits with an error code?

SYSTEM: STM32F103C8T6 72MHz 20KB RAM (64KB Flash)
DEBUG: CURRENT(blackmagic) EXTERNAL(blackmagic, jlink, stlink)
Library Dependency Finder ->
Collected 28 compatible libraries
Scanning dependencies...
No dependencies
Configuring upload protocol...
AVAILABLE: blackmagic, jlink, mbed, stlink, stlink
CURRENT: upload_protocol = stlink
openocd -s C:\Users\Maxi\.platformio\packages\tool-openocd -f scripts/interface/stlink.cfg -c "transport select hla_swd" -f scripts/target/stm32f1x.cfg -c "program {{.pioenvs\bluepill_f103c8\firmware.elf}}  verify reset; shutdown;"
GNU MCU Eclipse 32-bits Open On-Chip Debugger 0.10.0+dev-00392-gbe9ef0b0 (2018-01-12-10:20)
Licensed under GNU GPL v2
For bug reports, read
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.253616
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080003c8 msp: 0x20005000
** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 128kbytes
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000
wrote 9216 bytes from file .pioenvs\bluepill_f103c8\firmware.elf in 0.580417s (15.506 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20005000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20005000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20005000
verified 8416 bytes in 0.184331s (44.587 KiB/s)
** Verified OK **
** Resetting Target **
in procedure 'program'
in procedure 'reset' called at file "embedded:startup.tcl", line 529
in procedure 'ocd_bouncer'

*** [upload] Error 1
 [ERROR] Took 3.05 seconds 

I must also say that I must hold down the RESET button on the board for pio to be able to flash it. If I don’t, it can’t flash. Maybe that has something to do with the software reset over SWD instead of hardware reset of NRST (which is not connected)?

Anyways, the uploading program is solved, this is a problem of a different kind, I’ll maybe open a github issue that. Thanks for the fast response, as always.

Edit: You’re sure settings openocd as “upload” doesn’t break anything? OpenOCD is kind of both… Can flash the firmware and debug it (through a gdb server it opens).

Edit2: If I program the board with the mbed Framework, I don’t have to press down the reset button to flash it. Magic.

could you try in platformio.ini?

upload_protocol = mbed

Doesn’t make much sense, it’s a raw board with a ST-LINK v2. It doesn’t provide the pseudo flash-storage device other mbed-enabled boards (like ST Nucleo boards) have. Uploading fails with Error: Please specify 'upload_port' for environment or use global '--upload-port' option. For some development platforms it can be a USB flash drive (i.e. /media/<user>/<device name>). (There is no new COM device or flash drive found after I flashed the other firmware over stlink.)

As I said, consider this solved, flashing with the mbed firmware works fine without having to press the reset button, when flashing Arduino firmwares I need to press the reset button. Could also be an error on my side.

Please navigate to ~/.platformio/platforms/ststm32/ and this line before “debug[‘tools’][link] = {”

server_args.extend(["-c", "reset_config none"])

Did it help?

@ivankravets No, same behaviour: AVAILABLE: blackmagic, jlink, mbed, stlink, stlinkCURRENT: upload_protocol = s -
(I also tested libopencm3, and it can also re-flash without having to hold down the reset button.

AHA! I found out. Problem was actually solved a month ago and described here: SWD/JTAG disabled by the flashing? · Issue #61 · platformio/platform-ststm32 · GitHub

The default build flags disable the SWD debug port it seems? By adding build_flags = -DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG=1 I can flash as many times as I want without having to press the reset button.

With above flag it works fine, regardless of whether reset_config none is specified.

verified 8392 bytes in 0.186101s (44.037 KiB/s)
** Verified OK **
** Resetting Target **
shutdown command invoked
 [SUCCESS] Took 2.64 seconds 

Just revert back ~/.platformio/platforms/ststm32/ and run pio update. Now, all should work WIRHOUT extra configuration.


1 Like

I have just confirmed that this works with the staging version and no extra config.

platform =
board = bluepill_f103c8
framework = arduino
1 Like

Thank you so much!!! Now it should work with stable 4.0.1 version

1 Like

Has anyone else been successful uploading to bluepill using an stlink v2 clone probe and libopencm3?

I have a similar problem to the above. I am using bluepill, stlink v2 clone probe, libopencm3 framework. I am using VSCode 1.36.1 on Ubuntu 16.04.

I get a “Warn : UNEXPECTED idcode: 0x2ba01477; Error: expected 1 of 1 0x1ba01477” error when I try to upload. However when I use “st-util flash firmware.bin 0x8000000” using GitHub - stlink-org/stlink: Open source STM32 MCU programming toolset I am sucessful.

Here is my platformio.ini:

platform = ststm32
framework = libopencm3
board = bluepill_f103c8
upload_protocol =stlink

Here is the output from Platformio while trying to upload:
> Executing task in folder 190713-174118-libopencm3-blink: platformio run --target upload <

Processing bluepill_f103c8 (platform: ststm32; board: bluepill_f103c8; framework: libopencm3)
Verbose mode can be enabled via `-v, --verbose` option
PLATFORM: ST STM32 5.4.3 > BluePill F103C8
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash
DEBUG: Current (stlink) External (blackmagic, jlink, stlink)
PACKAGES: tool-stm32duino 1.0.1, framework-libopencm3 1.1.0, toolchain-gccarmnoneeabi 1.70201.0 (7.2.1), tool-openocd 2.1000.190422 (10.0)
LDF: Library Dependency Finder ->
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Checking size .pio/build/bluepill_f103c8/firmware.elf
Memory Usage ->
DATA:    [          ]   0.0% (used 0 bytes from 20480 bytes)
PROGRAM: [          ]   1.0% (used 684 bytes from 65536 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, dfu, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio/build/bluepill_f103c8/firmware.elf
GNU MCU Eclipse OpenOCD, 64-bitOpen On-Chip Debugger 0.10.0+dev-00593-g23ad80df4 (2019-04-22-20:18)
Licensed under GNU GPL v2
For bug reports, read
debug_level: 1
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
none separate
Warn : UNEXPECTED idcode: 0x2ba01477
Error: expected 1 of 1: 0x1ba01477
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1
================================================================================== [ERROR] Took 1.05 seconds ==================================================================================
The terminal process terminated with exit code: 1

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

Here is the output when I upload using

st-flash write firmware.bin 0x8000000
st-flash 1.5.1-30-g84f63d2
2019-07-14T11:30:04 INFO common.c: Loading device parameters....
2019-07-14T11:30:04 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-07-14T11:30:04 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2019-07-14T11:30:04 INFO common.c: Attempting to write 684 (0x2ac) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2019-07-14T11:30:04 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2019-07-14T11:30:04 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-07-14T11:30:04 INFO flash_loader.c: Successfully loaded flash loader in sram
  1/1 pages written
2019-07-14T11:30:04 INFO common.c: Starting verification of write complete
2019-07-14T11:30:04 INFO common.c: Flash written and verified! jolly good!

It shows I was able to successfully upload and the “blink” program was flashing the LED on my bluepill

Here is what I get when I do a “pio update”

    pio update
    Updating tool-scons                      @ 2.20501.7      [Up-to-date]
    Updating tool-unity                      @ 1.20403.0      [Up-to-date]
    Updating contrib-pysite                  @ 2.27.190418    [Up-to-date]
    Updating contrib-piohome                 @ 2.2.0          [Up-to-date]
    Updating tool-pioplus                    @ 2.5.2          [Up-to-date]

    Platform Manager
    Platform ST STM32
    Updating ststm32                         @ 5.4.3          [Up-to-date]
    Updating tool-stm32duino                 @ 1.0.1          [Up-to-date]
    Updating framework-libopencm3            @ 1.1.0          [Up-to-date]
    Updating tool-openocd                    @ 2.1000.190422  [Up-to-date]
    Updating framework-arduinoststm32        @ 3.10500.190327 [Up-to-date]
    Updating toolchain-gccarmnoneeabi        @ 1.70201.0      [Up-to-date]

Thanks for your help. PlatformIO is a nice tool.

I have successfully used it with a Black Pill board (main difference: correct resistor for USB bus) - no problem.

Are you sure your blue bill has an STM32F103C8 MCU? Can you provide the chip marking / full text on top of your MCU?

From the IDCODE, it looks as if you have a slightly different MCU.

1 Like

Chances are you don’t have an STM32F103C8T6 chip, but a Chinese clone, namely CS32F103C8T6 from China Key System & Integrated. That one is reported to use the 0x2ba01477 (as the IDcode or rather as the SW-DP tap id).

As a workaround, you can edit the file ~/.platformio/packages/tool-openocd/scripts/target/stm32f1x.cfg and change the line:

set _CPUTAPID 0x1ba01477


set _CPUTAPID 0x2ba01477

If it’s really the Chinese clone, you should also initiate that the chip gets added to OpenOCD and PlatformIO.


Thanks for the quick reply. I will only be able try your recommended fix later this week. I will update everyone with results.

Yes, this work around worked. by changing the above .cfg file, I was able to upload the firmware.elf successfully.

With regards to initiating the chip gets added to OpenOCD and PlatformIO, the markings on the chip say: STM32F103C8T6 991KA 93 MYS 807. So it could be the CS32F103C8T6 but it has been possibly relabeled. Should initiate the chip gets added with this STM label?

Strange. It probably doesn’t make sense to create a second stm32f1x configuration if it is not possible to distinguish the chips from their marking.

It would be great if the configuration could be changed such that it works with both tap IDs. I’m not an OpenOCD expert and I have no real clue how it is integrated into PlatformIO. Somebody with more knowledge about it would need to comment on this.

1 Like

You’ll probably want to open a ticket in the OpenOCD project ticket tracker: OpenOCD - Open On-Chip Debugger / Tickets

1 Like

Hi, ok I will do that. Will post here with any updates.

Thank you very much !

I was thinking my stlink-v2 (a clone without a doubt) was not recognized properly by platformio, instead it was indeed the stm32 chip, or rather its clone.

This workaround worked for me. The markings on the chip are : CKS32F 103C8T6 NK1M5 1845 E

It is a 128k flash chip btw.

Could you post the link to the ticket?