STM32F411CE (BlackPill) + STLink V2 + Arduino on Ubuntu

Development Platforms
1

Hello there,
I just bought a BlackPill board with STM32F411CEU6. I’m trying to upload a simple blink hello world:

#include <Arduino.h>

void setup() {
  pinMode(PC_13, OUTPUT);
  digitalWrite(PC_13, LOW);
  delay(500);
}

void loop() {
  digitalWrite(PC_13, HIGH);
  delay(500);
  digitalWrite(PC_13, LOW);
  delay(500);
}

With platformio.ini:

[env:genericSTM32F411CE]
platform = ststm32
board = genericSTM32F411CE
framework = arduino
upload_protocol = stlink

First upload seems to succeed with log:

xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:25)
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: 0xfffffffe msp: 0xfffffffc
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

But from the second if fails with this output error message:

xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:25)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

hla_swd
Error: timed out while waiting for target halted
embedded:startup.tcl:449: Error: ** Unable to reset target **
in procedure 'program' 
in procedure 'program_error' called at file "embedded:startup.tcl", line 474
at file "embedded:startup.tcl", line 449
*** [upload] Error 1

And the only way to erase the chip’s flash is to use the proprietary ST flasher tool.
What am I doing wrong?

2

Seems like the ST-Link isn’t able to reset the microcontroller. Either because it’s using the wrong method or pre-requisites for the method are not present.

  • Is the NRST of the STLink connected to the NRST of the target board?
  • Have you tried adding other reset configurations by adding to the platformio.ini
upload_flags =
  -c
  reset_config none

(as mentioned in board disco_l072cz_lrwan1 - [upload] Error 1 (OpenOCD init failed) · Issue #353 · platformio/platform-ststm32 · GitHub)
You can also try more reset options as mentioned in STM32 + VS Code + mbed upload issue: Error: libusb_open() failed with LIBUSB_ERROR_ACCESS Error: open failed - #12 by maxgerhardt.

3

Ok I will try with those options.

NRST is not connected to the STLink, but the strange thing is that first time works, from the second time stop working uploading method. But with proprietary method it works each time I erase or upload a new firmware.

Effectively last topic seems to be similar to mine.

4

Nope, there is something else:

this is the first uploading with
upload_flags =
-c
reset_config none

the log:

xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:25)
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 2000 kHz
Info : STLINK V2J35S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.196850
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
** Programming Started **
Info : device id = 0x10006431
Info : flash size = 512 kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked

Then if i try:

$ st-info --probe

Found 1 stlink programmers
 serial:     36006b063054373342332343
 hla-serial: "\x36\x00\x6b\x06\x30\x54\x37\x33\x42\x33\x23\x43"
 flash:      0 (pagesize: 0)
 sram:       0
 chipid:     0x0000
 descr:      unknown device

It is not able to communicate to device anymore and I have to ease flash using STM32 Flasher (enable connect on reset, because normal mode fails)

Second time that I try to upload my firmware gives me this log:

xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:25)
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 2000 kHz
Info : STLINK V2J35S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.196850
Info : stm32f4x.cpu: hardware has 0 breakpoints, 0 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Error: timed out while waiting for target halted
embedded:startup.tcl:449: Error: ** Unable to reset target **
in procedure 'program' 
in procedure 'program_error' called at file "embedded:startup.tcl", line 474
at file "embedded:startup.tcl", line 449

I don’t get what is wrong.

5

Maybe the STM32Duino firmware disables SWD functionality at start (or you have to enable it explicitly). When you upload the firmware via the Arduino IDE, is the behaviour the same?

hmm seems pretty recent to me, but maybe STSW-LINK007 - ST-LINK, ST-LINK/V2, ST-LINK/V2-1, STLINK-V3 boards firmware upgrade - STMicroelectronics has a more recent firmware for the STLink?

6

But with bluepill (stm32f1) works perfectly and it does the same if I use openocd from command line, but with the same stlink v2 and with the proprietary sw works perfectly.

7

Strange thing is that first time “seems” work, because it upload the executable, but the executable “don’t work”, the second time it is not accessible from openocd, and the only way to erase is with some tricks with proprietary flasher.
Maybe some other setting is wrong? For example memory address?

8

Other users have also experienced problems with STM32Duino and “generic” target, related to flash latency settings in the variant (STM32duino + STM32F405RG on VESC bldc controller - #15 by levivk). Maybe it’s worth a shot to try and change that?

Meaning they don’t do what the sketch should do? Like, a blinky example?

9

Yes, exactly.

I tried this: STM32duino + STM32F405RG on VESC bldc controller - #15 by levivk but nothing changed. It seems that it reach an inconsistent state in which it can’t access to memory without some other tricks…

10

Can you try the a board configuration? According to WeAct Studio BlackPill V2.0 (STM32F411CE) — PlatformIO latest documentation that’s board = blackpill_f411ce. It uses the same underlying variant folder Generic_F411Cx in the Arduino core but with a few different activated macros. Maybe those help.

If this still not works, please verify that it works in native Arduino IDE (they use STM32cubeprogrammer as an uplaod though).

1 Like
12

Yes, it works… Thank you very much, I looked at the 4 paragraphs for BlackPill in the upper part, but I didn’t see the configuration for the BlackPill V2 with STM32F411CE.
Thanks.