Thank you for that info. I am also powering my STM32 from the lower half of the Nucleo. That target power is a reporting pin (I thought) to report if the target has power before proceeding. Someone told me it was a high-impedance switchable port but I never checked the schematic to confirm. I believe I did test it with my DMM once though and got the same results as you.
I am curious, isn’t OpenOCD used by Arduino IDE? There is a file size and date difference between the two instances of OpenOCD.EXE I found.
Are you using anything special in your platformio.ini file? I would love to see what you have in there. I remember something about build-flags that fixed this for me last time, but I cannot find that info anywhere!!
My ST-LINK appears to be functioning normally with the latest driver.
though it must be said that upload_port = COM4 makes no sense since it uploads via the USB device of an STLink, that is ignored. Only when doing serial uploads, that would matter.
Can you try the firmware upgrade program and see if that makes a difference?
After that you can also try and change
upload_protocol = stlink
to
upload_protocol = mbed
on “This computer” there should be a “NODE_F411RE” virutal USB drive. That is opened by the STLink and accepts copying a firmware.bin file to it, that the Nucleo then tries to flash to the board. Usually done for mbed boards, but works on Nucleo boards, too. If that doesn’t work either, something is wrong with the STLink.
The boards are incorrectly wired. On the Nucelo SWD connector, pins 1 – 4 should be connected, not 2 – 5.
The Blue Pill should have an independent power supply, either via USB or some other 3.3V source.
VDD_TARGET is mainly used to measure the voltage of the target, not to deliver power. Some ST-Links can provide power as well but I’m not sure about the Nucelo’s ST-Link.
OK, I know I tried MBED before because I have it commented out in the ini file, so I changed it back, and now I am showing that the firmware.bin file is not found. The output is below.
By the way, I did drag the firmware.bin file over to the NODE_F411RE drive and it flashed just fine. The ONLY issue I had was that I had to press the reset button for it to run, and I cannot find an option to fix that like you can with the automatic mode dialog window in the utility.
Here is the verbose output (MBED UPLOAD). I would imagine that not being able to find the firmware bin file would be a real deal breaker. I wonder why, and where I can repair that.
> Executing task in folder stm32_rgb: C:\Users\Hop\.platformio\penv\Scripts\pio.exe run --verbose --target upload --environment genericSTM32F103C8 <
Processing genericSTM32F103C8 (platform: ststm32; lib_extra_dirs: ~/Documents/Arduino/libraries; board: genericSTM32F103C8; framework: arduino; upload_port: COM4; debug_tool: stlink; upload_protocol: mbed; build_flags: -DCORE_DEBUG_LEVEL=1)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F103C8.html
PLATFORM: ST STM32 (11.0.0+sha.8416130) (git+https://github.com/platformio/platform-ststm32.git) > STM32F103C8 (20k RAM. 64k Flash)
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash
DEBUG: Current (stlink) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
- framework-arduinoststm32 4.10900.200819 (1.9.0)
- framework-cmsis 2.50501.200527 (5.5.1)
- tool-dfuutil 1.9.200310
- tool-openocd 2.1000.200630 (10.0)
- tool-stm32duino 1.0.2
- toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
MethodWrapper(["checkprogsize"], [".pio\build\genericSTM32F103C8\firmware.elf"])
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [ ] 4.1% (used 844 bytes from 20480 bytes)
Flash: [== ] 15.3% (used 10016 bytes from 65536 bytes)
.pio\build\genericSTM32F103C8\firmware.elf :
*** [upload] COM4\firmware.bin: No such file or directory
section size addr
.isr_vector 268 134217728
.text 8792 134217996
.rodata 1088 134226788
.init_array 16 134227876
.fini_array 8 134227892
.data 136 536870912
.bss 708 536871048
.noinit 0 536871756
._user_heap_stack 1540 536871756
.ARM.attributes 41 0
.comment 102 0
.debug_frame 1192 0
Total 13891
<lambda>(["upload"], [".pio\build\genericSTM32F103C8\firmware.bin"])
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, mbed, serial, stlink
CURRENT: upload_protocol = mbed
MethodWrapper(["upload"], [".pio\build\genericSTM32F103C8\firmware.bin"])
Use manually specified: COM4
MethodWrapper(["upload"], [".pio\build\genericSTM32F103C8\firmware.bin"])
============================================================================================== [FAILED] Took 5.90 seconds ==============================================================================================
The terminal process "C:\Users\Hop\.platformio\penv\Scripts\pio.exe 'run', '--verbose', '--target', 'upload', '--environment', 'genericSTM32F103C8'" terminated with exit code: 1.
Terminal will be reused by tasks, press any key to close it.
This is what I have for the SWD on the Nucleo. As far as I can see, it is also the same on the discovery. The first pin is the VDD_TARGET like you mentioned and is not used. So I am using 2-4. Pin 5 is connected (NRST) with a jumper but is NOT used and not connected to RESET on the STM32F103. 2 is SW Clock, 3 is GND, and 4 is SW DIO. Besides, it has to be hooked up correctly because I use to be able to connect, a couple of years ago, and I reconnected this based on images and data from that time period. Also, Arduino IDE and STLINK are able to upload without issue, which would not work if my connections were incorrect. UNLESS for some reason, the command line arguments from OpenOCD include using VDD_TARGET to confirm connection. Hmm.
EDIT: And I have always used the 3.3v on the F411RE board for power. I am not sure why it is not available on the SWD port. Maybe it is not a best practice to use the power from the NUCLEO attached target board. I have never had any problems though. Usually, when I have other devices connected, I already have a power bus set up, instead of just powering the target.
You are correct. By looking at the connectors on both boards, I’ve counted 4 wires. But there are 5. And with your description, I also understand where the brown one goes.
@maxgerhardt, @manuelbl I GOT IT!!! YAY!
Thank you max for the nudge in the right direction. Indeed, upload_port was not needed, and when I commented it out, the upload worked! I looked over the last failed verbose output and noticed that the path of the firmware that was not found was COM4/firmware.bin. This is really odd actually that the firmware would be expected at a subdirectory of COM4 just because a com port was used. Weird. I am sure there is a reason.
Anyway, the only issue I have now is that the board does not auto reset. Perhaps the use of the NRST line might be for this purpose. Checking…
And indeed it is!! I will have to use my scope to see if there is a pulse on that line, but after I wired it up, the application ran as if I did a hard reset. Now that is TWO long-term issues solved.
Thank you gentlemen for your help and suggestions, I appreciate it!!
EDIT: [after-thought] - Also, Max, I appreciate the tip about the MBED drive and dragging code over to it. I would imagine that the same result would occur if a firmware file was copied to that path via a script. That would almost completely negate the need to jump through all those hoops with OpenOCD! I wonder if I can set PIO to just run a script and copy that file over when I wish to upload. I’ll have to explore that someday.
This happened because when using upload_protocol = mbed, then upload_port is respected, as the path you want to copy the firmware too. If you’d want to do this manually you’d say upload_port = E:, for example.
It’s good that that upload method is working now, but then the OpenOCD upload is still not working? Without that, you also cannot use debugging, as that requires the SWD interface.
Have you tried the firmware upgrade of the STLink already? LINK Firmware version : V2J35M26 is two majors behind the current
Maybe also uninstall the driver in the Windows device manager and install them again using the latest version found in ST-Link utility (C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK_USB_V2_1_Driver)
@maxgerhardt Out of curiousity, that image you shared that is your version… yours was out of date also? Or am I reading that wrong? V2J34M25… mine is V2J35M26 (newer?) and the current one is V2J37M26 (newest?). I just want to make sure I got that straight. So technically, if I also had your version then it would also work? This would indicate that there is just a problem with my version, which correct, is out of date. So… just saying, if the current version does not work also, and this is the issue, then I could roll back to your V2J34M25 and it should work. Again, if the ST-LINK version is the issue. Right?
I’m on it. Thank you sir. And PLEASE correct me if I am missing something.
Yes my initial one was older than yours, but for me it worked with that older and also the newest version. So if you upgrade to the newest version as well there’s no version difference between us, and if it still fails, it must be something else.
In that case I’d ask you to open a PlatformIO CLI and execute
I ran what you posted but I got an error and that path “C:\Users\Hop.platformio\tool-openocd\bin\openocd” does not exist on my system. I instead tried to run it with “\packages” added and the output is below. If I am suppose to have a “C:\Users\Hop.platformio\tool-openocd\bin” folder in addition to and looks like “C:\Users\Hop.platformio\packages\tool-openocd\bin” then there might be the problem. I just figured you forgot "\packages\ in your path, after .platformio.
@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.
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).
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?
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
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.
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 2.1.0.0
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.
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.
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 1.0.0.0 dated 2013. But when I look at the version in the ST-LINK utility, it is 5.1.2.0. Here is a pic…
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!!
