Cannot upload via stlink. OpenOCD init failed

I am trying to upload via stlink to a bluepill - but it fails.
The error message isn’t particular helpful.

<lambda>(["upload"], [".pio/build/bluepill_f103c8/firmware.elf"])
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
openocd -d2 -s /Users/tcurdt/.platformio/packages/tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "reset_config none" -c "program {.pio/build/bluepill_f103c8/firmware.elf}  verify reset; shutdown;"
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2021-10-17-00:18)
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 : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
none separate

Info : clock speed 1000 kHz
Error: open failed
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1

Maybe this is because this is using OpenOCD x86_64 while I am on an arm64 machine? Although even that should in theory work through Rosetta2.
Any pointers?

And you have an ST-Link V2 connected to your Bluepill’s 3V3, GND, SWDIO, SWCLK (+NRST) pins?

Yes, that’s correct.
It’s still connected like it was when it was working with the Arduino IDE.

The pio config is just:

[env:bluepill_f103c8]
platform = ststm32
board = bluepill_f103c8
framework = arduino

Can you still upload via the Arduino IDE? What is the invocation for the OpenOCD when you activate File → Preferences → Verbose Upload and then upload?

I need to check. It was a different, x86 machine. Maybe I can try the old install.
I don’t have the Arduino IDE on this machine. I am planning to go pio only :slight_smile:

After searching through a few tickets on github I found suggestions to change
~/.platformio/packages/tool-openocd/scripts/target/stm32f4x.cfg

# original
# reset_config srst_nogate
# working
reset_config srst_nogate connect_assert_srst
# untested
# srst_only separate srst_nogate srst_open_drain connect_assert_srst

…and it suggests the upload with the stlink worked afterwards.

CURRENT: upload_protocol = stlink
openocd -d2 -s /Users/tcurdt/.platformio/packages/tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "reset_config none" -c "program {.pio/build/bluepill_f103c8/firmware.elf}  verify reset; shutdown;"
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2021-10-17-00:18)
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 : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
none separate

Info : clock speed 1000 kHz
Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.246123
Info : stm32f1x.cpu: Cortex-M3 r1p1 processor detected
Info : stm32f1x.cpu: target 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 = 64kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

But the blink program is still not blinking.

What is the exact code running on it? Also, some boards have their on-board LED on different pins (PC13 / PB12). Is it a regular bluepill board or a barebones STM32F103C8 chip? Are the BOOT0/1 jumpers on the board set to both GND so that the chip boots from flash (and will not go into bootloader mode)?

Exactly this:

#include "Arduino.h"

#define LED PC13

void setup()
{
  pinMode(LED, OUTPUT);
}

void loop()
{
  digitalWrite(LED, HIGH);
  delay(1000);
  digitalWrite(LED, LOW);
  delay(1000);
}

The silk screen says PC13 - so I used PC13.

Both jumper are set to 0 all the time - I didn’t touch them.
IIUC that’s not required when uploading via stlink, correct?

Alright - now it gets crazy.

I have 5 boards seemingly of the same kind.
1 board just uploads and blinks.
1 board just uploads - but does not blink. (broken led?)
3 boards where the upload fails like this:

CURRENT: upload_protocol = stlink
openocd -d2 -s /Users/tcurdt/.platformio/packages/tool-openocd/scripts -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "reset_config none" -c "program {.pio/build/bluepill_f103c8/firmware.elf}  verify reset; shutdown;"
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2021-10-17-00:18)
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 : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
none separate

Info : clock speed 1000 kHz
Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.246123
Error: init mode failed (unable to connect to the target)
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1

This is with reset_config srst_nogate connect_assert_srst

Can you additionally connect NRST of the ST-LinkV2 to the reset (“R”, upper row 4th pin) pin?

I didn’t have to try the NRST route. After some tries of - writing a new bootloader and uploading with boot0 set 1, I now have 4 boards where the upload works.

I can’t say I feel comfortable as I cannot really pinpoint the final reason for the change.
But for other people reading - I was experimenting with:

st-info --probe
st-flash erase
st-flash write ./generic_boot20_pc13.bin 0x8000000

Now it looks like this on upload:

$ pio run -t upload
Processing bluepill_f103c8 (platform: ststm32; board: bluepill_f103c8; framework: arduino)
--------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/bluepill_f103c8.html
PLATFORM: ST STM32 (15.2.0) > BluePill F103C8
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash
DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES: 
 - framework-arduinoststm32 4.20100.211028 (2.1.0) 
 - framework-cmsis 2.50700.210515 (5.7.0) 
 - tool-dfuutil 1.9.211020 
 - tool-openocd 2.1100.211028 (11.0) 
 - tool-stm32duino 1.0.1 
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 11 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:   [          ]   4.0% (used 828 bytes from 20480 bytes)
Flash: [==        ]  17.1% (used 11208 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.11.0+dev (2021-10-17-00:18)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

hla_swd
none separate

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

But I have 1 out 4 boards where PC13 is just constantly on.
The very same bin does work fine and blinks on the other 3 pills.

Of course I know checked the crystal :wink: and tried to visually compare the boards - but at least I don’t see a difference.

The LED also turns on immediately when the board gets power.
It’s also weird that the reset button does not seem to do anything. On the other boards the PA13 turns off during reset. Could it be a broken output?

Any other idea?