[BUG] ST-Link firmware verification - No ST-LINK detected message since 1.4.x update.

[gcrisa]

On Windows 10, I just updated (again) to the 1.4.2 version, hoping to solve this issue, yet nothing changed.

Already tried a clean install (again) and re-installed the latest STM32CubeProgrammer: nothing changed.

Will ST handle this sooner or later please? Or at least give some help in diagnosing the problem? Thanks

[gcrisa]

I tried setting up an OpenOCD debug confguration, adding -d and -l options to log the output (see attached image): got no debug at all...

I then tried by manually starting stlinkserver.exe first, with the same -d3 option as before, then again launching the OpenOCD debug. Still no debug from the openocd.exe, but got the one from stlinkserver.exe which I am attaching.

[ilyaz yilmaz]

Actually I Updated to 1.4.2 and I faced the same problem. I removed all files and all programs.

I installed from STM32Cubeide from zero but it didnt work. I m waiting a solution???

[LaurentL]

OK, openocd also not working as expected.

You can test libusb doing this :

Get libusb from here : https://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.22/

unzip libusb-1.0.22.7z

Open windows command prompt and run listdevs.exe and xusb.exe -d and gives the execution log

> Cd C:\yourpath_to_unzip_file\libusb-1.0.22\examples\bin32

> listdevs.exe

>xusb.exe -d

If stlink devices are found there should be something with stlink usb PID in the list (0483 is ST VID).

> listdevs.exe

…

0483:374b (bus 3, device 26) path: 7

…

xusb log is longer.

[gcrisa]

Just tried. listusb.exe gives no output, so I'm guessing it cannot find any devices.

xusb.exe returns a log which I am attaching. It seems that it sees the root hub to which the st-link is connected (line 38 in the log) but then somehow the enumeration fails (L39).

So it seems the issue is in the libusb actually... Could you guess why the CubeIDE 1.3.x is working? Perhaps it uses an older libusb version? If so I could try download it and replace the current with the older one...

[gcrisa]

By the way. I just found and tried the 1.0.33 version (link) and it works! It enumerates all the devices, incl. my st-link...

PS D:\libusb-1.0.23\examples\bin32> .\listdevs.exe
8086:9d2f (bus 1, device 0)
05c8:03b7 (bus 1, device 2) path: 6
04f3:0c1a (bus 1, device 4) path: 8
0483:374e (bus 1, device 5) path: 9
0bda:0129 (bus 1, device 3) path: 7
8087:0a2b (bus 1, device 1) path: 5

[LaurentL]

Ah ah. good to know. Thanks.

[gcrisa]

Moreover, I see that the libusb-1.0.dll included in the stlink_server did not changed (compared it with another PC in the lab, which still has CubeIDE 1.3 on it). So I'm really wondering why it was working before...

Also, I don't know if this does makes sense but I tried to replace the dll inside the stlink_server folder first with the more recent one I found (version 1.0.23.11397) and then with the version you linked to me (1.0.22.11312, which should be the same as the default one): in both cases the stlinkserver.exe fails to start, so I am guessing ST distributes a modified libusb, right?

[SMacD.1]

Google suggests Error 10048 is "address already in use".

I have 1.4.2 working with an ST-Link programming device on Windows 10 (fully updated but not with the May 2020 update yet).

Are you running anti-malware on both PCs exhibiting the problem? Try disabling that temporarily. Sometimes they're overly aggressive about blocking networking actions.

[gcrisa]

Ok, I just love malware. Keeps my wife away from my computer...

[PJ SA.1]

i have the same problem too, 1.4.x work perfectly on my new HP laptop, but not working on my old DELL laptop. no st-link detected when star debug. is the problem solved ?