[macOS] ST-Link-v1 driver issues / libusb problems #574
Comments
|
I'm not sure you need the driver for stlinkv1 on newer OS X. If you get your hands on a stlinkv2 this is recommended as they also can measure target voltage. The stlinkv1 is deprecated some time ago by ST Microelectronics. |
|
A lot of Discovery boards still ship with the stink-v1. I'm using the STM32VLDiscovery board which has this version too. |
|
Have you tried texane/stlink tools without driver? |
|
@xor-gate it does't work. |
|
Probably the kernel attaches to SCSI driver, so you are unable to see it. |
|
ioreg says I am not sure, but shouldn't it be IOUSBAttachedSCSI or something? |
|
@xor-gate seems st-util is able to detect and connect to board using prior version of libusb, I tried v1.0.9 libusb@master devices list libusb@v1.0.9 devices list it is might be related to libusb/libusb#282 somehow |
|
@amok that was a detailed investigation. I'm glad we see this fixed in libusb. Good work! |
|
Thanks @amok but I'm still getting an error. No other programs using the port. |
|
I am getting exactly the same error :-( |
|
@xor-gate sorry for confusion @karpenet I am not sure we have the same issues (if so - sorry for spamming your thread). have you tried to downgrade libusb? |
|
Hi @amok its not a problem to discus here which probably could cause the problem. |
|
I'm having a similar issue (as per issue #587). I have built stlink from the latest source and installed it with homebrew on separate occasions. Without the driver / kext I get: And with the driver I get: I've had to modify the install.sh file so that it installs the 10.10 kext on Sierra. I also have the kext-dev-mode flag set but I'm not quite sure that method even does anything anymore on Sierra. Sierra itself does detect the device (I can see it in the System Profiler, deviceID and productID seem to be correct too). As an experiment I installed Ubuntu 17.04 in a VM on the same system, built stlink from the same source, reconnected the board to the system and when VMWare Fusion asked me to choose a "destination" for the STLink I chose "Ubuntu". Started st-util -1 and it worked flawlessly in Ubuntu. I'm inclined to believe that this might be a kext issue. As long as there's no kext installed it is detected but can't be claimed, most likely due to the mass storage issue. Once the kext is installed however stlink can't find it. As of this moment I'm running whatever version libusb was installed automagically (most likely 1.0.21?) and I honestly have no idea how to install an older version (like 1.0.9) to see if this resolves the problem on my end as well. |
the simplest way probably would be to git clone libusb repo and then compile it on v1.0.9 tag and then symlink binaries to |
|
@amok I've been trying to do that but I fear something is just not going quite right. I've got one folder in my home dir where I keep all my STM32 related stuff which is where I execute all of these commands from. Here are the literal steps that I've taken so far: So far, so good. I've checked the files and I see numerous references to v 1.0.9. Now it get's sketchy. The first command to run, according to the INSTALL file, is './configure'. However that won't fly: The only executable file I can see in the folder is autogen.sh, which gives me this: After that I can run "make" and "make install": I've checked /usr/local/lib and there are 4 new libusb related files there: Running st-util -1 again gives me the exact same outcome: To be sure I've removed the files again and downloaded the 1.0.9 libusb tarbal from sourceforge. This one does have the configure file and executing it gives me this: Then "make": and "make install" Again, I see 4 new files in /usr/local/lib, which have the exact same name as the ones that showed up using the github source. st-util -1 gives me the same error yet again: Am I doing something oddly wrong here? (sorry for the long post, I figured it'd be best to get all console output in here in case I missed something) Edit: Edit 2: Edit 3: Edit 4: In the examples folder there's a file called "xusb.c" that has issues listing usb devices with a vendor code >= 0x80. I did a quick fresh clone, made the alterations to the .c file myself (just a few lines of code), did ./configure, make and make install and ran ./listdevs again. Wonders above wonders, the V1 shows up too now. Now to get to the meat and potatoes, I have a feeling this is not solely a libusb issue. Apparently the implementation of libusb changed somewhere between 1.0.9 and 1.0.21 and this might be an issue with how st-link tries to access the list of devices, similarly to the "xusb.c" example. Although I must admit that I'm running the same st-link on the Ubuntu VM where it works without issues. |
|
Got the same issue and managed to sort it loading the .kext file. Problem was is the new protections in 10.13. After restart was able to load the .kext and st-util -1 works correctly. |
|
Ok, I'm still failing with OS X 10.13.6. I've done I took 10.10 kext and moved it to When I load it I see everything's okay: but kextstat gives me nothing.
st-util -1 does not work: Still, kextunload works well, it reports that the kext was unloaded. |
|
What does st-util say when you run as root with sudo? It is not a the perfect situation but we can see if it is a permission problem. |
|
I'm able to see Product ID: 0x3744 This is what I see from libusb 1.0.9 The same command shows nothing in libusb-1.0.22 =( Edit:
then |
|
I'm seems OK with OS X 10.13.6. I've done I took 10.10 kext and moved it to When I load it I see everything's okay: And then And then got this below (you must rebuild some extra tests: and my st-link is v1:
|
Nightwalker-87
changed the title
|
As @jasonhouang mentioned before, the root of this problem is a system security setting introduced by Apple with OS X El Capitan (OS X 10.11) in 2015. The so called System Integrity Protection (SIP) is active per default and prevents the operating system amongst other things to load unsigned Kernel Extension Modules (kext). Thus the ST-Link-v1 driver supplied with the tools, which installs as a kext, remains not functional, while SIP is fully activated (as is per default). Action needs to be taken here by booting into the recovery mode where a terminal console window needs to be opened. In contrast to the previous approach I would NOT RECOMMEND to disable SIP completely as with the command Further details can be found here: https://forums.developer.apple.com/thread/17452 |
|
I am going to add the instructions above to our project documentation in order to make them publicly accessible and will subsequently close this issue as resolved. |
Nightwalker-87
changed the title
Nightwalker-87
changed the title
Nightwalker-87
changed the title
|
Here we actually had two separate problems in one issue:
|
Added documentation on how to solve a failed detection of the ST-Link-v1 programmer in macOS v10.11 and later. (Closes stlink-org#574, stlink-org#587)
Unable to build driver on macOS Sierra 10.12.3
Output:
Expected/description:
Tried building with Yosemite and El Capitan configurations as in driver readme, none seem to work.The text was updated successfully, but these errors were encountered: