(SOLVED) Cannot Upload to STM32F103 "BluePill" using ST Link on Nucleo Board

@maxgerhardt Mine look the same. Sorry if I am missing something obvious.
Just to be sure, here is my current platformio.ini with changes back to ST-LINK and com4 commented out.

platform = ststm32
lib_extra_dirs = ~/Documents/Arduino/libraries
board = genericSTM32F103C8
framework = arduino
;upload_port = COM4
debug_tool = stlink
upload_protocol = stlink
;upload_protocol = mbed
build_flags = -DCORE_DEBUG_LEVEL=1

ST-Link Debug Hardware IDs ST-Link Dongle Hardware IDs

Okay well now we’re entering voodoo territory. The USB device is there, you have the same driver version as me, with the expected VID and PID, and the fully updated ST-Link firmware version (I assume).

According to OpenOCD fail to open STM32 Nucleo board - Page 1 there may also be problems when plugging it into a USB3.0 port vs a USB2.0 port. Can you try different ports?

Have you restarted your computer already and then directly opened PlatformIO to make sure only PlatformIO interacts with the STLink, and no other program?

Does disabling antivirus make a difference, if active?

Does installing a different driver for “ST-Link debug” from the path mentioned above, installed by the latest version of STSW-LINK004 - STM32 ST-LINK utility (replaced by STM32CubeProgrammer) - STMicroelectronics, make difference?

When you download the latest openOCD release from Releases · xpack-dev-tools/openocd-xpack · GitHub (xpack-openocd-0.10.0-15-win32-x64.zip), unpack it, open a terminal / cmd.exe, cd into the main folder and do a

bin\openocd.exe -s scripts -f interface\stlink.cfg -c "transport select hla_swd" -f target\stm32f1x.cfg

does it throw the same error?

I agree it’s a problem connecting to the ST-Link via USB (and not between ST-Link and target).

OpenOCD searches by PID/VID combination. Either it doesn’t find such a combination (unlikely given the details from the device manager) or the device has already been taken by some other process. So I would recommend to search again for anything that interferes or interacts with the device: programs, crashed programs, extensions, virus and security tools etc.

As a note: On Windows, I originally had WinUSB drivers installed. I don’t remember installing anything so the device has probably declared this driver and Windows installed it automatically. With those drivers, OpenOCD worked but ST-Link Utility would fail. In the mean time, I’ve installed the ST-Link drivers and now both programs work. So driver issues are less likely.

1 Like

Another interesting side information would be what Zadig (https://zadig.akeo.ie/) says when you do Options → List All Devices and select the ST-Link Debug (Interface 0) device. For it shows WinUSB drivers v2.1.0.


Using that program you can also try and load a different driver for the device and then again check if OpenOCD is able to pick it up.

On my Windows machine, it looks the same: WinUSB v2.1.0.0.

Interestingly, Zadig could replace it with WinUSB v6.1.7600.1683.

Device manager says that the drivers are provided by STMicroelectronics with signer “STMICROELECTRONICS (GRENOBLE 2) SAS”, version

The driver details point at C:\WINDOWS\system32\DRIVERS\winusb.sys, provided by Microsoft Corporation, version 10.0.19041.1.

So three different version for the same thing?

I don’t quite understand how it fits together. Most likely, the STM driver provides an INF file only and then installs stock USB drivers: WinUSB for interface 0, USB MSC for interface 1 and USB CDC ACM for interface 2. It’s a good thing it doesn’t provide any driver code. But it doesn’t explain why it ST-Link Utility wouldn’t work before updating the driver.

@maxgerhardt That is a bit of a list to work and I will be doing it in the next few hours. Making a holiday visit to my Mother-in-Law. Also, I have a similar setup on one of my laptops and will take that with me along with the hardware and test it also. If THAT works, at least I know it is isolated to my desktop machine and can go after it there. AND have something local to compare with. I know a LOT more now than when I started this thread, thank you sir. I will return with my results.

There is one anomaly I am having… the driver for my devices. I tried to update the driver but my Windows tells me I already have the best version installed. When I list available drivers, the one that comes with the firmware update is not listed. SO I am at wits-end to how I can update to the new driver. I tried uninstalling the hardware and removing the software box checked, and then plugging it back in, but the older driver attaches itself again. Sigh.
This is the packaged USB Driver.

This is the list I have available to pick manually from. If I browse the folder that has the newest driver that came with the update, Windows tells me that the best driver is already installed.
USB Drivers

The Virtual COM port (VCP) driver isn’t very important, that’s just the serial / UART interface. The firmware is uploaded via the SWD interface that is handled by the “ST-Link Debug” device.

…Hm. After going through my list above I’d then suggest you actually uninstall ST-Link Utility, uninstall the device from the device manager, make sure it’s an “unknown device” then after re-plugging it, and then try the drivers that are installed when installing STM32CubeProg - STM32CubeProgrammer software for all STM32 - STMicroelectronics.

But, one thing at a time.

@maxgerhardt, @manuelbl

OK, I did as you suggested and that was indeed the solution. And not only did it solve my initial issue, but 3 others as well. That interesting extra feature of dragging a firmware.bin file to the NODE_F411RE drive broke in the process as it’s available space was less than the size of the firmware file. But after reinstalling ST-LINK, that has fixed itself as well. And fortunately, I did not need to dig into the version of OpenOCD that was being used by PIO.

I tested upload, and debug features and both work now. THANK YOU!!!

An interesting observation, actually two. But here is the first. When I check the version number of the USB driver now, it still shows dated 2013. But when I look at the version in the ST-LINK utility, it is Here is a pic…New ST-LINK

The second observation… I went to the wrong tab when coming back to this thread and noticed another poster. At first I thought someone piggy-backed on my thread, then realized it was an open tab from my exhausting search for an answer. I did notice though that you two guys were the same two that helped someone else on this similar issue. I am glad you found my thread and was able to help me!!!

Thanks again to the both of you for the assist!! I certainly appreciate your time and effort with helping me!!

1 Like