Upload to STM32 blackpill_f411ce fails over STLink-V2 - Incompatible library version

Development Platforms
21

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)
22

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

23

You could try this:

  1. Open a new Terminal window
  2. Set PATH to minimum: export PATH=/usr/bin:/bin:/usr/sbin:/sbin
  3. Clear DYLD_LIBRARY_PATH: export DYLD_LIBRARY_PATH=
  4. Attempt to connect to the STM32F4xx board:

~/.platformio/packages/tool-openocd/bin/openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

and see if this gives the same error.

24

@djix123 Same error message.

@m4ngu Welcome to the PlatformIO Community! You’ll find all sorts of fantastic material here, Folks are super helpful. What version of macOS are you running?

I have no STM32 upload issues on a fresh macOS 11.6.2 VM (upgraded from 11.6.1) after STM32CubeProgrammer v2.90 (latest) on top of PlatformIO / VScode.

No STM32 / STLinkV2upload issues on macOS12.1 (after upgrade from 12),macOS 10.15.7ormacOS 10.14.6`.

The STM32 / STLinkV2 upload issues still exist on macOS 11.6.2 on my Macbook Pro.

btw - The MacDependency output for macOS 11.6.2 and macOS 11.6.2 VM (where STM32 uploads work) are the same. Some dependencies (listed in red text) have no exports. One of the problem is that these tools only provide static analysis.

1 Like
25

I have tried two different machines (Intel and M1) with two different macOS versions (11.6 and 12.1) and can’t reproduce it.

The dynamic linker (dyld) on macOS can be a bit tricky and is different from Linux. Environment variables such as DYLD_LIBRARY_PATH can overrule which libraries are used (unless SIP is enabled for the executable). So the otool -L output is only reliable if run with the same environment variable.

PlatformIO manipulates DYLD_LIBRARY_PATH. In my case, I can see that it adds the path ~/.platformio/packages/tool-dfuutil/lib when I upload to an STM32 using ST-Link. This directory contains – you guessed it – libusb in the outdated version 3.0.0. But the upload is still successful. So openocd uses a different libusb, probably the one in ~/.platformio/packages/tool-openocd/libexec.

Things to check for:

  • Are any DYLD... environment variables set? If so, what to?
  • Is there a libusb library in any of these directories: $(HOME)/lib, /usr/local/lib, /lib, /usr/lib? If so, what version is it (use otool -L)?
26

That is very strange. A couple of other thoughts to help

  1. Create a new user account so that everything is fresh and minimally install PlatformIO and try

  2. Download the latest version of xpack openocd (as this looks like the one used by PlatformIO) and try that form he command line. ( Release xPack OpenOCD v0.11.0-3 (with support for Apple Silicon) · xpack-dev-tools/openocd-xpack · GitHub )

As per @manuelbl I’ve also tried replicating this problem on a 11.6.2 Intel Mac and a 12.1 M1 Mac but have not been unable to.

I have STM32CubeProgrammer installed, but that doesn’t cause any issue.

27

@manuelbl How can I view what path PlatformIO adds to DYLD_LIBARRY_PATH when uploading to a STM32 with STLink?

28

The following are the only libusb occurrences I have on macOS 11.6.2.

/usr/local/lib/libusb-1.0.0.dylib
/usr/local/Cellar/libusb/1.0.24/lib/libusb-1.0.0.dylib

/Users/quark11/.platformio/packages/tool-openocd@2.1000.200630/bin/libusb-1.0.0.dylib
/Users/quark11/.platformio/packages/tool-openocd/libexec/libusb-1.0.0.dylib
/Users/quark11/.platformio/packages/tool-dfuutil/lib/libusb-1.0.0.dylib

/Users/quark11/Library/Arduino15/packages/sandeepmistry/tools/openocd/0.10.0-dev.nrf5/bin/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.1/toolchain/lib/libusb-1.0.0.dylib
/opt/nordic/ncs/v1.7.1/toolchain/Cellar/libusb/1.0.24/lib/libusb-1.0.0.dylib

Out of the above, only ~/..platformio/packages/tool-dfuutil/lib/libusb-1.0.0.dylib is version 3.0.

/Users/quark11/.platformio/packages/tool-dfuutil/lib/libusb-1.0.0.dylib:
	/usr/local/opt/libusb/lib/libusb-1.0.0.dylib (compatibility version 3.0.0, current version 3.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 1560.12.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)

So, pio openocd, when run for STM32 upload via ST-Link may be picking this version, as reported in the error,

dyld: Library not loaded: @loader_path/../libexec/libusb-1.0.0.dylib
  Referenced from: /Users/quark11/.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
29

That’s interesting re: tool-dfuutil … I don’t have a lib directory in the version I have installed. The package version is: “version”: “1.9.211020”.

Can you move that libusb- out of the way - e.g. rename and try again?

30

I have modified ~/.platformio/penv/lib/python3.9/site-packages/platformio/builder/tools/pioplatform.py (added a print call).

31

@djix123 @manuelbl @maxgerhardt @ivankravets

How about that! ~/.platformio/packages/tool-dfuutil/lib/libusb-1.0.0.dylib was the culprit!

Replacing the ~/.platformio/packages/tool-dfuutil/lib/ files (or simply moving out the lib directory to another location) with those from version 4.0 libusb fixed the problem.

The current version of PlatformIO installs ~/.platformio/packages/tool-dfuutil. It was on my fresh macOS 11.6.x VM (Mac Mini 2012).

The odd thing is that version 3.0 of ~/.platformio/packages/tool-dfuutil/lib/libusb-1.0.0.dylib is also on macOS 12.1, macOS 10.15.7 and macOS 10.14.6. However, it doesn’t seem to affect the STM32 / STLINKV2 uploads. I suspect that on those macOS versions libusb version 4.0 gets used in the DYLD_LIBRARY_PATH.

The latest STM32CubeProgrammer v2.90 uses version 2.0 of libusb.

Anyway, the libusb versions used by PlatformIO needs to be updated to v4.0 for compatibility to v4.0.

Thank you all for assisting in the issue. It is much appreciated!.

1 Like
32

Great! Glad it’s working now.

33

Glad to hear it’s working. I still don’t understand why I couldn’t reproduce the problem and it’s working on many machines. I guess we don’t understand all aspects of the problem yet.

34

If one-time usage of the dfu upload protocol (by e.g. setting upload_protocol = dfu) and then going back to OpenOCD / stlink upload installs tool-dfu and tool-openocd in parallel in such a way that every subsequent invocation of tool-openocd fails because it loads the wrong libusb version, that’s a problem and needs to be fixed on the PlatformIO side – maybe someone can try to reproduce that?

35

I’ve run some additional tests on STM32 using stlink / dfu uploads on macOS 11.6.2.

  1. Removed ~/.platformio/packages/tool-dfuutil/

  2. Performed a STM32 dfu upload. It was successful (as expected), tool-dfuutil @ 1.9.200310 installed.

  3. The downloaded ~/.platformio/packages/tool-dfuutil/lib/libusb-1.0.0.dylib is v3.0.

  4. Removed pio openocd to force a new download of openocd when attempting STM32 upload using stlink. tool-openocd @ 2.1100.211028 installed.

  5. Performed a stlink upload. It failed, as ~/.platformio/packages/tool-dfuutil/lib/libusb-1.0.0.dylib was v3.0.

  6. Replaced ~/.platformio/packages/tool-dfuutil/lib/ with libusb v4.0.

  7. Performed a stlink upload. Succesful upload.

  8. Performed another dfu upload. It was successful.

9 Performed a couple of subsequent stlink and dfu uploads. All were successful.

PlatformIO needs to ensure that the compatible versions of libusb are loaded for STM32 stlink & dfu uploads.

From the tests conducted, replacing the ~/.platformio/packages/tool-dfuutil/lib/ files with those from version 4.0 libusb resolves STM32 stlink & dfu uploads.

1-removed-dfu
1-removed-dfu1218×242 29.6 KB

2-first-dl-dfu-v3-test
2-first-dl-dfu-v3-test1510×1562 209 KB

3-removed-openocd-first-openocd
3-removed-openocd-first-openocd1314×288 48.6 KB

4-stlink-failed-with-first-dl-openocd
4-stlink-failed-with-first-dl-openocd1430×446 70.6 KB

5-replaced-libsub-with-v4-stlink-upload-works
5-replaced-libsub-with-v4-stlink-upload-works1184×574 64.3 KB

6-switched-to-dfu-works-with-libusb-v4
6-switched-to-dfu-works-with-libusb-v41458×1540 205 KB

36

It is curious. I don’t have dfu-utils installed on my main development machine, but I do on another machine I occasionally use. (VSCode / PlatformIO / ststm32).

I checked the versions of libusb present, and STM32CubeProgrammer is 2.0, dfu-utils is 3.0 and openocd is 4.0 as per @zpm1066 .

Interestingly, though, when I try an debug with stlink (via) openocd I have no problems at all. PlatformIO / openocd finds the correct libusb and works fine.
(I’d never remembered having problems, but wanted to explicitly confirm).

It feels like something is being set in the environment that’s causing the version 3.0 to be picked up, since its not in a ‘standard’ directory (e.g. /usr/lib, /usr/local/lib) it must be explicitly being set somewhere.

37

I’m running MacOS Sierra10.12.6
pretty old version I’m afraid,

38

macOS 10.12 Sierra is great! I have it on a few Macs.
Sierra was the version that had the full macOS Server. I have one setup since it came out, running 24x7, using the server for VPN plus as a private cloud.

39

Well, I’m happy with it but when it comes to update things always get messages about my OS not being supported for being too old.
BTW I’ve fixed the problem about libusb-1.0.0.dylib, replacing the one in
~/.platformio/packages/tool-dfuutil/lib/libusb-1.0.0.dylib
by the updated one from
libexec/libusb-1.0.0.dylib
now I get another error, but at least I see the led in the programmer to blink when tried to flash:
Captura de pantalla 2021-12-20 a las 15.50.20
any idea what’s going wrong here?

40

You can try a few things:

  • start holding the reset button, press the Upload button in VSCode, release reset button when OpenOCD output appears and appears to pause
  • connect NRST from the ST-Link programmer to NRST of the target board