Cannot upload or debug STM32 with ST-Link

1

platformio.ini:

platform = ststm32
board = genericSTM32F103C8
board_build.f_cpu = 36000000L
framework = arduino
upload_protocol = stlink
debug_tool = stlink

I can connect to the target with “STM32 ST-Link Utility” when using hardware reset:

15:02:15 : ST-LINK SN : 56FF…
15:02:15 : V2J34S0
15:02:15 : Connected via SWD.
15:02:15 : SWD Frequency = 4,0 MHz.
15:02:15 : Connection mode : Connect Under Reset.
15:02:15 : Debug in Low Power mode enabled.
15:02:16 : Device ID:0x410
15:02:16 : Device flash Size : 128KBytes
15:02:16 : Device family :STM32F10xx Medium-density

But I cannot connect to it from PlatFormIO / VSCode / Windows 10.

Neither programming (flashing)

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: 1

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

*** [upload] Error 1

nor debugging:

undefinedC:\Users\user\.platformio\packages\toolchain-gccarmnoneeabi\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory.
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target...
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
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 1000 kHz
Info : STLINK V2J34S0 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.903616
Error: init mode failed (unable to connect to the target)

.pioinit:13: Error in sourced command file:
Remote communication error. Target disconnected.: Success.

and

[Window Title]
Visual Studio Code

[Content]
Failed to launch GDB: .pioinit:13: Error in sourced command file:
Remote communication error. Target disconnected.: Success. (from interpreter-exec console “source .pioinit”)

[Open launch.json] [Cancel]

Versions:

Version: 1.50.1 (user setup)
Commit: d2e414d9e4239a252d1ab117bd7067f125afd80a
Date: 2020-10-13T15:06:15.712Z (3 wks ago)
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.18363

You're up-to-date!
PlatformIO 5.0.2 is currently the newest version available.

PLATFORM: ST STM32 (8.1.0) > STM32F103C8 (20k RAM. 64k Flash)
HARDWARE: STM32F103C8T6 36MHz, 20KB RAM, 64KB Flash
DEBUG: Current (stlink) External (blackmagic, jlink, stlink) 
PACKAGES:
 - framework-arduinoststm32 4.10900.200819 (1.9.0)
 - framework-cmsis 2.50501.200527 (5.5.1)
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)

Does PIO connect using hardware reset? If not, how can it be enabled?

2

What does the wiring between the ST-Link and your MCU look like? Are you using a 10-pin connector with all 10 wires connected, or are you using a setup with 4 pins only? How do you power your board – through the ST-Link or with a separate power supply (e.g. via USB connection to board)?

3

Sorry.
Using the onboard ST-Link of the f407 discovery board with 5 wires.
The target is powered independently - measures 3.3 V.
Setup has not changed or even moved between using ST-Link Utility and VSCode/PIO.

4

Just to better understand: You are using the ST-Link of a STM32F4 Discovery board to connect to a STM32F1 chip on another board, right?

Which five wires have you connected? Does it include NRST?

Do you use the SWDIO and SWDCLK for other things than just ST-Link connection?

For your configuration, the OpenOCD command line looks like:

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

(with additional line breaks)

You can try to modify the scripts interface/stlink.cfg and target/stm32f1x.cfg to achieve the same reset/connect behavior.

The default settings seem to be:

cortex_m reset_config sysresetreq
reset_config srst_nogate

I’m unsure which configuration would correspond to “hardware reset”. In the past, I was successful using reset_config none separate. But it might be different in your case. Some documentation is here:

Additional documentation is here:

5

Thanks for your help.

Correct.

Connections as per https://www.st.com/resource/en/user_manual/dm00039084-discovery-kit-with-stm32f407vg-mcu-stmicroelectronics.pdf p. 17. including NRST.

IO and CLK are not connected to anything.

Your command for flashing works fine when run from .platformio\packages\tool-openocd\bin> with an absolute path for the .elf.

.platformio\packages\tool-openocd\scripts\interface\stlink.cfg only contains

adapter driver hla
hla_layout stlink
hla_device_desc "ST-LINK"
hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753

but .platformio\packages\tool-openocd\scripts\target\stm32f1x.cfg has about 90 lines.

I have previously tried reset_config srst_only without success.

How can I increase the verbosity level for OpenOCD when run by PIO?

6

When I set debug_level 3 in .platformio\packages\tool-openocd\scripts\target\stm32f1x.cfg, PIO does not handle the output which seems to time out with

...
Debug: 113 10032 command.c:352 register_command_handler(): registering 'stm32f1x.cpu'...

I’ll try this on a blue-pill

7

Strange.

Another way to set the debug level of OpenOCD is described here:

8

Changing \.platformio\platforms\ststm32\builder\main.py:274 to

elif upload_protocol in debug_tools:
    openocd_args = [
        # "-d%d" % (2 if int(ARGUMENTS.get("PIOVERBOSE", 0)) else 1)
        "-d3"
    ]

also sets the debuglevel higher.

I can flash / debug a "bluepil"l much more reliably.
So I’ll recheck my wiring and hardware. Maybe the controller has an issue as well.

9

Seems to have been an issue with the wires. Different, shorter wires appear to have resolved the problem.

Embarrassing, and such a waste of time. Thanks again for your help!

1 Like