How to set up ST-Link V2 - platform ststm32

I also have problems by uploading with STLink, like this topic:

In my case, I use V2. But the mesages are similar as posted in the thread as linked above:

Linking .pioenvs\genericSTM32F103CB\firmware.elf Checking program size text data bss dec hex filename 6316 1920 312 8548 2164 .pioenvs\genericSTM32F103CB\firmware.elf Building .pioenvs\genericSTM32F103CB\firmware.bin Looking for upload disk... Auto-detected: COM4 Uploading .pioenvs\genericSTM32F103CB\firmware.bin 2017-04-06T19:00:10 INFO C:\Users\User\Downloads\stlink\src\common.c: Loading device parameters.... 2017-04-06T19:00:10 WARN C:\Users\User\Downloads\stlink\src\common.c: unknown chip id! 0*** [upload] Error -1

The PIO ini files has this info:

[env:genericSTM32F103CB] platform = ststm32 board = genericSTM32F103CB framework = arduino upload_protocol = stlink build_flags = -v

STLink utility recognizes and handles the probe correctly.

Does anyone know any solution?

Did you try it with official St utility??
Can you try it with the st utility and report your findings??

As I already mentioned in my previous post: ST-Link utility recognizes and uses the probe correctly, I am able to flash binary files with it.
I am on win10 x64 machine.

How can I add as parameter the chip ID of the probe? Which file should I edit?

On going through the git repo for the stlink utility several things pop out and scream.

@ivankravets It looks like the texane/stlink being bundled with platformio is 1.1 change… 1.3 change is the latest version. Can this be updated to the 1.3 version??
This post throws some light.

Can you try two things as outlined in the posts

This post pretty much reflects your problem.

Put your board into serial bootloader mode, erase and then flash the board as given in one of the replies.
Please try and check it works.

Alternatively, first issue a seperate command to erase the chip and then upload

From what it appears, its a texane/stlink issue rather than platformio issue. Maybe we should wait for a proper fix from their end??

Please file an issue Issues · platformio/platform-ststm32 · GitHub

Well, a follow up.
I tried the same what @stevestrong tried with his nucleo board.Except I tried with my Disco F030R8 board.
I, too, faced the same issue as posted by anirbax in another thread.

As i said, I tried it with the st-util bundled with platformio and no success . I manually downloaded the 1.3 binaries from texane/github and tried invoking the same command with 1.3 binary and voila! it works fine.


I ll open an issue as you suggested and maybe that might solve a couple of issues with the flashing and debugging.


PS: Actually another good samaritan has already opened the same issue.

I opened aa new issue, but saw that previous post later.

OK, it seems that it somehow started to launch stlink flasher correctly.
I closed ATOM and all running Java applications, restarted ATOM and it looks like the upload with stlink now works.


it does not work correctly.
The linker has specified a start address of 0x8002000 (VECT_TAB_ADDR=134225920), but the probe will still flash to 0x8000000:

Archiving .pioenvs\genericSTM32F103CB\libFrameworkArduino.a
Linking .pioenvs\genericSTM32F103CB\firmware.elf
Checking program size
text       data     bss     dec     hex filename
11924      2136     936   14996    3a94 .pioenvs\genericSTM32F103CB\firmware.elf
Building .pioenvs\genericSTM32F103CB\firmware.bin
Looking for upload disk...
Auto-detected: COM4
Uploading .pioenvs\genericSTM32F103CB\firmware.bin
Flash page at addr: 0x08003400 erased
 13/13 pages written
2017-04-06T22:51:01 INFO C:\Users\User\Downloads\stlink\src\common.c: Loading device parameters....
2017-04-06T22:51:01 INFO C:\Users\User\Downloads\stlink\src\common.c: Device connected is: F1 Medium-density device, id 0x20036410
2017-04-06T22:51:01 INFO C:\Users\User\Downloads\stlink\src\common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2017-04-06T22:51:01 INFO C:\Users\User\Downloads\stlink\src\common.c: Attempting to write 14060 (0x36ec) bytes to stm32 address: 134217728 (0x8000000)
2017-04-06T22:51:02 INFO C:\Users\User\Downloads\stlink\src\common.c: Finished erasing 14 pages of 1024 (0x400) bytes
2017-04-06T22:51:02 INFO C:\Users\User\Downloads\stlink\src\common.c: Starting Flash write for VL/F0/F3 core id
2017-04-06T22:51:02 INFO C:\Users\User\Downloads\stlink\src\flash_loader.c: Successfully loaded flash loader in sram
2017-04-06T22:51:02 INFO C:\Users\User\Downloads\stlink\src\common.c: Starting verification of write complete
2017-04-06T22:51:02 INFO C:\Users\User\Downloads\stlink\src\common.c: Flash written and verified! jolly good!

How can I change the flashing start address?
Is there a script which I can patch somehow, making the flash start address dependent on some compiler flags?

Furthermore, it seems that it loads the data into SRAM? Or it just the flash loader which is running from SRAM?

Uplading with ST-Link V2 seems to work reliably now.
However, after upload I always have to press the reset button, otherwise it won’t re-initialize the board.

Is there a way to make the st flasher to automatically reset the board after uploading?

Arduino IDE uses for the SMT32F103 devices the “ST-LINK_CLI.exe” command line utility (available under “.platformio\packages\tool-stm32duino\stlink”) to upload the binary. This has the “-Rst” argument which resets the board after upload.
But PlatformIO does not uses this tool for uploading, right?