There’s no custom installation of libusb. I did install the latest libusb via new yesterday.
Which libusb does PlatformIO use?
From the error message, it would appear to be from
.platformio/packages/tool-openocd/libexec .
I have also tried removing tool-openocd & stm32 packages, then restarting VScode. This still results in the dyld: Library not loaded error.
It’s odd that the same setup has no issues in STM32 uploads on macOS Catalina & Mojave.
Any other suggestions? Thanks.
@ivankravets What versions of macOS are you running?
For me, STM32 uploads work fine on macOS 10.14.6 and macOS 10.15.7. The STM32 upload issue occurs only on macOS 11.6.1.
All other platform uploads (nRF52, ESP32, RP2040, AVR) work fine on macOS 11.6.1, macOS 10.14.6 and macOS 10.15.7.
I used 11.6 before and didn’t have issues. Now, 12.1, updated a few days ago. Just tried and it works.
@maxgerhardt what is your macOS version?
I have no Mac to test, hence why I tagged you 
For me, the issue is on macOS 11.6.1. The STM32 uploads work fine only Macs with macOS 10.14.6 & macOS 10.15.7.
I’m going to use locate (from terminal) to find all installs of libusb-1.0.0.dylib on the MBP running macOS 11.6.1, then check their hash & compare with the ones on macOS 10.14.6 & macOS 10.15.7. It’s possible the wrong version of libusb-1.0.0.dylib is being pickup up.
Which libusb-1.0.0.dylib does PlatformIO use when attempting a STM32 upload?
My PATH has /usr/local/bin first, so the brew version of libusb-1.0.0.dylib should get invoked.
There are several locations where libusb-1.0.0.dylib resides or is sym-linked.
/usr/local/lib/libusb-1.0.0.dylib. (symlinks to /usr/local/Cellar/libusb/1.0.24/lib/libusb-1.0.0.dylib)
/Applications/STMicroelectronics/STM32Cube/STM32CubeProgrammer/STM32CubeProgrammer.app/Contents/MacOs/Drivers/FirmwareUpgrade/native/mac_x64/libusb-1.0.0.dylib
/Applications/STMicroelectronics/STM32Cube/STM32CubeProgrammer/STM32CubeProgrammer.app/Contents/MacOs/bin/libusb-1.0.0.dylib
/opt/nordic/ncs/v1.7.0/toolchain
I’ll check compare their sha256 hash.
There is a wrapper script inside tool-openocd package. It manipulates with LD_PATH.
Thanks.
Does PlatformIO use the following for STM32 uploads via STLInkv2?
.platformio/packages/tool-openocd/bin/openocd
.platformio/packages/tool-openocd/libexec/libusb-1.0.0.dylib
or, Does PlatformIO use the /usr/local/lib/libusb-1.0.0.dylib?
btw - On different macOS versions, the sha256 hash is different for /usr/local/lib/libusb-1.0.0.dylib.
Mabye executing PIO’s openocd version with these extra environment variables turned on gives you more info where the library comes from? macos - MacOSX: which dynamic libraries linked by binary? - Stack Overflow
Or otool -L <path to opencod> (windows - Discovery of Dynamic library dependency on Mac OS & Linux - Stack Overflow)
Thanks. An interesting utility that I have not come across before.
Here’s what I get.
macOS 11.6.1 (where the issue exists):
macOS 10.15.7 (STM32 uploads work):
The STM32 upload error was:
Both macOS versions of .platformio/packages/tool-openocd/libexec/libusb-1.0.0.dylib have version 4.0.0 compatibility, so pio openocd should load the libexec/libusb-1.0.0.dylib.
Does this mean that the PlatformIO version of openocd is not being invoked for STM32 / STLInkv2 upload?
A little confused! I’ll investigate further.
Using Xcode, I’ve built executables for the MacDependency tool (A GUI version of otool utility, similar to Windows Dependency Walker, that shows all dependent libraries and frameworks of a given executable, dynamic library or framework on macOS. MacDependency tool was built separately using Xcode 12.4 on macOS 10.15.7 & Xcode 13.1 on macOS 11.6.1.
MacDependency tool is available at GitHub - kwin/macdependency: MacDependency shows all dependent libraries and frameworks of a given executable, dynamic library or framework on Mac OS X.
From the pio openocd results, it appears that on macOS 11.6.1, some of the dependencies are not being satisfied (MacDependency entries in red below are missing). I have no idea what application (STMProgrammerCube?) installs these missing items. I’m not sure on the their importance. It just could be a red herring!
Here are the results from MacDependency.
macOS 11.6.1:
macOS 10.15.7:
I’m not sure what to try next. Perhaps a small fresh install of macOS 11.6.x, PlatformIO, and STM32CubeProgrammer on a separate external drive.
This problem exists only in PlatformIO / macOS 11.6.1 for STM32 / STLinkV2 uploads, as I am able to upload code to blackpill_f411ce in Arduino IDE1.8.16 using STLinkV2.
Weird! Any other suggestions would be welcome!
Max, @ivankravets - I performed a fresh install of macOS 10.16, PlatformIO, and STM32CubeProgrammer (SetupSTM32CubeProgrammer-2.9.0). I got the exact same error message as before when attempting uploads to a STM32 blackpill_f411ce board using STLinkV2.
I have install of macOS 12 Monterey VM running under VMware Fusion Pro on a Mac Mini 2012 & VMware ESXi Server on a Mac Mini 2012.
Mac OS 11 or 12 are not officially supported on a Mac Mini 2012 but the VMs run fine without any changes.
I’ll test out STM32 uploads via STLinkV2 under a macOS 12 Monterey VM.
STM32 uploads via STLinkV2 under a macOS 12 Monterey VM work fine.
Btw - I’ve been testing out a W5500 Ethernet breakout across a suite of nRF52840, Raspberry Pi Pico, ESP32, STM32, and a micro:bit v2 boards.
I’m still puzzled why the STM32 / STLinkV2 upload doesn’t work on macOS 11.6.1. I’ll try a further test on a fresh macOS 11.6.1 VM.
I tried another test, this time installed PlatformIO and VScode but no STM32CubeProgrammer (SetupSTM32CubeProgrammer-2.9.0) in a fresh macOS 11.6 VM.
I can confirm that STM32 uploads to a blackpill_f411ce board using STLinkV2 were successful. It’s possible that the latest STM32CubeProgrammer installer conflicts somehow or it could be some other libusb conflict.
I’ll run some further tests on the macOS 11.6 VM to rule out possible conflict with the STM32CubeProgrammer installer, though I have my doubts. The libusb conflict may be elsewhere.
I’m not quite sure how I’ll fix the issue on my main macOS 11.6 system.
@maxgerhardt, @ivankravets, Do you have any other suggestions? Thanks.
There must be something wrong with the LDPATH or the order thereof. I’m not good enough on Mac to know what the loading order and priorities are though – or if STM32CubeProgrammer somehow intereferes with it. I had another person check it with no STM32CubeProgrammer installed and there were no problems. (https://github.com/CommunityGD32Cores/ArduinoCore-GD32/issues/55#issuecomment-996730655)
Thanks Max.
I’ll try to rule out STM32CubeProgrammer (v2.9) in some further testing over the weekend, though I have it installed on macOS 10.4.6 & macOS 10.15.7 where I don’t have any STM32 upload issues. The STM32CubeProgrammer is needed by Arduino IDE for STLink uploads.
@ivankravets Would you or one of your Dev colleagues know what may be incorrect with the LDPATH?
Can you run these commands and post the output:
file ~/.platformio/packages/tool-openocd/bin/openocd
otool -L ~/.platformio/packages/tool-openocd/bin/openocd
otool -L ~/.platformio/packages/tool-openocd/libexec/libusb-1.0.0.dylib
Thanks.
Here is the output from macOS 11.6.2. It’s the same as on macOS 11.6.2 VM where all STM32 / STLINKV2 uploads work fine.
quark11:~ quark11$ file ~/.platformio/packages/tool-openocd/bin/openocd
/Users/quark11/.platformio/packages/tool-openocd/bin/openocd: Mach-O 64-bit executable x86_64
quark11:~ quark11$ otool -L ~/.platformio/packages/tool-openocd/bin/openocd
/Users/quark11/.platformio/packages/tool-openocd/bin/openocd:
@loader_path/../libexec/libftdi1.2.dylib (compatibility version 2.0.0, current version 2.5.0)
@loader_path/../libexec/libhidapi.0.dylib (compatibility version 1.0.0, current version 1.0.0)
@loader_path/../libexec/libusb-1.0.0.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1671.10.106)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1560.12.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
@loader_path/../libexec/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
quark11:~ quark11$ otool -L ~/.platformio/packages/tool-openocd/libexec/libusb-1.0.0.dylib
/Users/quark11/.platformio/packages/tool-openocd/libexec/libusb-1.0.0.dylib:
/Users/ilg/Work/openocd-0.11.0-2/darwin-x64/install/libs/lib/libusb-1.0.0.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1454.90.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)Hi, I have same issue after some updates,
with those commands I’ve got this:
iMac-de-Jesus-2:old-StepFader mkII jesus$ file ~/.platformio/packages/tool-openocd/bin/openocd
/Users/jesus/.platformio/packages/tool-openocd/bin/openocd: Mach-O 64-bit executable x86_64
iMac-de-Jesus-2:old-StepFader mkII jesus$ otool -L ~/.platformio/packages/tool-openocd/bin/openocd
/Users/jesus/.platformio/packages/tool-openocd/bin/openocd:
@loader_path/../libexec/libftdi1.2.dylib (compatibility version 2.0.0, current version 2.5.0)
@loader_path/../libexec/libhidapi.0.dylib (compatibility version 1.0.0, current version 1.0.0)
@loader_path/../libexec/libusb-1.0.0.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1671.10.106)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1560.12.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
@loader_path/../libexec/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
iMac-de-Jesus-2:old-StepFader mkII jesus$ otool -L ~/.platformio/packages/tool-openocd/libexec/libusb-1.0.0.dylib
/Users/jesus/.platformio/packages/tool-openocd/libexec/libusb-1.0.0.dylib:
/usr/local/opt/libusb/lib/libusb-1.0.0.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.8.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
I have no idea what’s going on, but looking at this I would say that the file has the right version:
@loader_path/…/libexec/libusb-1.0.0.dylib (compatibility version 4.0.0, current version 4.0.0)
and this is what I get when trying to upload:
Processing blackpill_f401cc (platform: ststm32; board: blackpill_f401cc; framework: arduino)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/blackpill_f401cc.html
PLATFORM: ST STM32 (15.1.0) > WeAct Studio BlackPill V2.0 (STM32F401CC)
HARDWARE: STM32F401CCU6 84MHz, 64KB RAM, 256KB Flash
DEBUG: Current (blackmagic) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
- framework-arduinoststm32 4.20100.211028 (2.1.0)
- framework-cmsis 2.50700.210515 (5.7.0)
- tool-dfuutil 1.9.200310
- tool-openocd 2.1100.211028 (11.0)
- tool-stm32duino 1.0.1
- toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 11 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/blackpill_f401cc/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [ ] 1.3% (used 852 bytes from 65536 bytes)
Flash: [ ] 4.5% (used 11796 bytes from 262144 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, serial, stlink
CURRENT: upload_protocol = stlink
Uploading .pio/build/blackpill_f401cc/firmware.elf
dyld: Library not loaded: @loader_path/../libexec/libusb-1.0.0.dylib
Referenced from: /Users/jesus/.platformio/packages/tool-openocd/bin/openocd
Reason: Incompatible library version: openocd requires version 4.0.0 or later, but libusb-1.0.0.dylib provides version 3.0.0
*** [upload] Error -6
any help would be much appreciated, thanks in advance
You could try this:
~/.platformio/packages/tool-openocd/bin/openocd -f interface/stlink.cfg -f target/stm32f4x.cfg
and see if this gives the same error.