How to flash a Blue Pill with an ST-Link?

ppelleti · April 16, 2021, 6:29am

I’m attempting to upload the cmsis-blink example to a Blue Pill board using ST-Link, as a quick sanity check to make sure I know what I’m doing before I move on to more complicated things. (And apparently I don’t know what I’m doing.)

I’m using PlatformIO 5.1.1 on Ubuntu 20.04, and I tried uploading to the board like this:

ppelleti@patrick64:~/src/platform-ststm32/examples/cmsis-blink$ pio run -e 'bluepill f103c8' --target upload
Processing bluepill f103c8 (platform: ststm32; framework: cmsis; board: bluepill_f103c8)
--------------------------------------------------------------------------------
Tool Manager: Installing platformio/tool-stm32duino @ ~1.0.1
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Tool Manager: tool-stm32duino @ 1.0.1 has been installed!
Tool Manager: Installing platformio/tool-openocd @ ~2.1000.0
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Tool Manager: tool-openocd @ 2.1000.200630 has been installed!
Tool Manager: Installing platformio/tool-dfuutil @ ~1.9.190708
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Tool Manager: tool-dfuutil @ 1.9.200310 has been installed!
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/bluepill_f103c8.html
PLATFORM: ST STM32 (12.1.1) > BluePill F103C8
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash
DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
 - framework-cmsis 2.50501.200527 (5.5.1)
 - framework-cmsis-stm32f1 4.3.1
 - tool-dfuutil 1.9.200310
 - tool-ldscripts-ststm32 0.1.0
 - tool-openocd 2.1000.200630 (10.0)
 - tool-stm32duino 1.0.1
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
Warning! Cannot find a linker script for the required board! An auto-generated script will be used to link firmware!
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/bluepill f103c8/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.1% (used 28 bytes from 20480 bytes)
Flash: [          ]   0.6% (used 396 bytes from 65536 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio/build/bluepill f103c8/firmware.elf
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:27)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

hla_swd
none separate

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

*** [upload] Error 1
========================= [FAILED] Took 12.23 seconds =========================

Environment      Status    Duration
---------------  --------  ------------
bluepill f103c8  FAILED    00:00:12.235
==================== 1 failed, 0 succeeded in 00:00:12.235 ====================

I’m unclear exactly what “unable to connect to the target” means. Does it mean that it could not connect to the ST-Link probe? Or does it mean that the ST-Link probe could not connect to the Blue Pill board?

I wondered if this could be a udev problem, but it doesn’t look like it is. Here is how my probe shows up:

ppelleti@patrick64:/etc/udev/rules.d$ lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 0483:3748 STMicroelectronics ST-LINK/V2
Bus 004 Device 002: ID 04f2:0939 Chicony Electronics Co., Ltd USB Optical Mouse
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 058f:6363 Alcor Micro Corp. Mass Storage Device
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 04ca:002f Lite-On Technology Corp. USB Multimedia Keyboard
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

and it looks like that is covered by a udev rule:

ppelleti@patrick64:/etc/udev/rules.d$ fgrep 3748 99-platformio-udev.rules
ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE="0666"

What is the next thing I should try?

manuelbl · April 16, 2021, 7:46am

The “target” is the STM32 MCU. So “unable to connect to target” is a communication issue between the ST-Link and the MCU. The communication between PlatformIO/your computer and the ST-Link likely works.

Things to check:

Ensure that the wiring between the ST-Link and the Bluepill is correct and working. It should include GND, SWDIO, SWCLK and VCC (3.3V).
Ensure that the Bluepill is correctly powered. The VCC pin on the ST-Link is mainly to measure the voltage, not to provide it. Some ST-Links will provide power if they don’t measure any voltage. But others don’t and you will have to power the board separately, e.g. via USB.
Try to press the reset button when the ST-Link tries to initially connect to the board.
Change the BOOT0 jumper to 1 and try to connect to the target like so. If it works, the current firmware likely reconfigures SWCLK/SWDIO.
Upload a benign program via the serial connection (setting the BOOT0 jumper first) to ensure to remove the problematic firmware. Then switch back to ST-Link.

ppelleti · April 16, 2021, 8:37am

Thanks! Here are my results so far:

Pretty sure I’ve got it correct. On both ends, I’ve connected yellow => 3V3, orange => SWDIO, red => SWCLK, and brown => GND.

I’m just powering the Blue Pill through the ST-Link, but it seems to be working. On the Blue Pill, the red (power) LED is lit, and the green (PC13) LED is flashing rapidly. (Presumably this is the default program that comes on the board. This is a brand-new Blue Pill which has never been used before.)

This resulted in the same error message as before.

I can give this a try. How do I tell pio to upload via a serial connection? “serial” isn’t one of the choices of available protocols:

AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, mbed, stlink

maxgerhardt · April 16, 2021, 11:22am

Confirming, picture looks perfectly fine.

The timing there may be delicate – you need to hold down the reset button for the entire time, then release it as soon as you see some OpenOCD output. Might take a few tries.

It may also have something to do with power. The 3.3V pin is usually a power/voltage-detect pin. What happens if you power the board too via the USB port?

That’s indeed weird. bluepill_f103c8 doesn’t allow upload_protocol = serial, but if you switch to genericSTM32F103C8, it does.

github.com

platformio/platform-ststm32/blob/dcc41b20872eabb745f750d91dcef22a860ddddc/boards/genericSTM32F103C8.json#L39-L46


      
          "protocols": [
            "jlink",
            "cmsis-dap",
            "stlink",
            "blackmagic",
            "serial",
            "dfu"
          ],

not sure why, it’s the exact same chip after all.

For the upload via serial you will need a USB-serial adpater connected to the USART pins where the bootloader communicates. Per https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf this is

ppelleti · April 16, 2021, 11:57pm

I’m not sure that’s possible. There’s only a fraction of a second between the first line of OpenOCD output and the error message.

Instead, I just added another wire to connect the reset pin of the ST-Link probe to the reset pin of the Blue Pill. That ought to work in theory, right?

(However, in practice it did not work.)

I gave that a try, but it did not change the behavior.

I switched to genericSTM32F103C8 and used upload_protocol = serial, and it worked! The program was successfully uploaded.

Does that mean my ST-Link probe is no good? I have a CMSIS-DAP probe; maybe I’ll try that next.

ppelleti · April 17, 2021, 7:35am

I added this to the platformio.ini file:

[env:genericSTM32F103C8]
platform = ststm32
framework = cmsis
upload_protocol = cmsis-dap
board = genericSTM32F103C8

And then I hooked up my CMSIS-DAP probe to the Blue Pill, and gave it a try:

ppelleti@patrick64:~/src/platform-ststm32/examples/cmsis-blink$ pio run -e genericSTM32F103C8 --target upload
Processing genericSTM32F103C8 (platform: ststm32; framework: cmsis; board: genericSTM32F103C8)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F103C8.html
PLATFORM: ST STM32 (12.1.1) > STM32F103C8 (20k RAM. 64k Flash)
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash
DEBUG: Current (blackmagic) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
 - framework-cmsis 2.50501.200527 (5.5.1)
 - framework-cmsis-stm32f1 4.3.1
 - tool-dfuutil 1.9.200310
 - tool-ldscripts-ststm32 0.1.0
 - tool-openocd 2.1000.200630 (10.0)
 - tool-stm32duino 1.0.1
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
Warning! Cannot find a linker script for the required board! An auto-generated script will be used to link firmware!
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Compiling .pio/build/genericSTM32F103C8/FrameworkCMSIS/gcc/startup_stm32f103xb.o
Compiling .pio/build/genericSTM32F103C8/FrameworkCMSIS/system_stm32f1xx.o
Compiling .pio/build/genericSTM32F103C8/src/main.o
Linking .pio/build/genericSTM32F103C8/firmware.elf
Checking size .pio/build/genericSTM32F103C8/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.1% (used 28 bytes from 20480 bytes)
Flash: [          ]   0.6% (used 396 bytes from 65536 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, serial, stlink
CURRENT: upload_protocol = cmsis-dap
Uploading .pio/build/genericSTM32F103C8/firmware.elf
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:27)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

swd
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1
========================== [FAILED] Took 1.31 seconds ==========================

Environment         Status    Duration
------------------  --------  ------------
genericSTM32F103C8  FAILED    00:00:01.311
==================== 1 failed, 0 succeeded in 00:00:01.311 ====================

So it still fails, although the error message is a little bit different than when using the ST-Link probe.

I know the CMSIS-DAP probe works, because I’ve used it many times with ATSAMD MCUs. (Though I haven’t used it with PlatformIO before.)

So either there’s something in my setup that’s preventing both the ST-Link and the CMSIS-DAP from working, or else my Blue Pill is remarkably resistant to being programmed with SWD.

I have more Blue Pills I could try. (Although they were all purchased at the same time from the same vendor on AliExpress.)

Besides trying another Blue Pill, is there anything else I should try?

ppelleti · April 17, 2021, 8:20am

I tried another Blue Pill with the ST-Link probe, and had the same results as the first.

Then I remembered I had a F411 Discovery board lying around. I added an entry to platformio.ini for the Discovery board:

[env:disco_f411ve]
platform = ststm32
framework = cmsis
board = disco_f411ve

I tried programming the Discovery board over its built-in ST-Link, and it worked!

Since the Discovery board works, should I just assume that I got a bad batch of Blue Pills on AliExpress?

maxgerhardt · April 17, 2021, 11:27am

Your ST-Link might require a firmware update? Can you first install STM32CubeProg - STM32CubeProgrammer software for all STM32 - STMicroelectronics and see if it connects to the Bluepill board without problems?

If not, try to upgrade with STSW-LINK007 - ST-LINK, ST-LINK/V2, ST-LINK/V2-1, STLINK-V3 boards firmware upgrade - STMicroelectronics.

ppelleti · April 17, 2021, 9:40pm

It immediately said I needed a firmware update. (For some reason it would not let me take a screenshot of this dialog box, so I had to use a camera.)

I tried that. It told me the firmware version was unknown:

I clicked the “Open in update mode” button. This printed out a couple of lines on standard output:

JNI command error 0x1001 after cmd [-15, -128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
JNI command error 0x1001 after cmd [-15, -128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

And then it displayed an error message at the bottom of the GUI:

So it looks like my ST-Link probe is no good.

Can we focus on the CMSIS-DAP probe instead? I know it works in general. Shouldn’t it have worked to upload this program to the Blue Pill? What can I do to investigate why the CMSIS-DAP probe isn’t working?

maxgerhardt · April 18, 2021, 9:06am

Which exact cmsis-dap probe are you using? A stlink can also be a cmsis-dap compliant probe.

ppelleti · April 18, 2021, 9:22am

I’m using the MAX32625PICO board, which comes flashed with default firmware which makes it act like a CMSIS-DAP probe. It’s small and cheap. I’ve used it before to flash SAMD microcontrollers using an OpenOCD script.

maxgerhardt · April 18, 2021, 10:33am

Does the probe expose the virtual usb disk? You can try upload_protocol = mbed then if OpenOCD fails to connect to the chip. If this method also doesn’t work, then there must be something wrong with the connections or the power.

ppelleti · April 18, 2021, 5:49pm

It does. However, my understanding is that the MAX32625PICO’s default firmware only knows how to flash other Maxim MCUs via the virtual USB disk. (Because the firmware needs to know some details about the target device.) However, CMSIS-DAP can be used with any MCU, because OpenOCD handles the details about the target, and the probe can just be a “dumb” pass-through.

This page is where I read that. It says:

All images support CDC virtual UART and HID CMSIS-DAP debugging/programming with any target. Only MSD drag-n-drop programming is specific to the targets listed above.