STM32CubeProgrammer - No ST-LINK Detected

[MWill.18]

Hi all,

I have been struggling to get Atollic 9.3.0 to start a debug session, failing at the load point where it tries to use the STM32CubeProgrammer CLI (1.3.0 in that release of Atollic).

I thought I would download the STM32 ST-LINK Utility and this connects and finds the device OK.

I then tried the STM32CubeProgrammer stand-alone application V2.0.0 but this shows No ST-LINK detected with the same board that worked for the ST-LINK Utility program.

STM32CubeProgrammer will find the device when performing a firmware upgrade and also run through this process ok. But it won't find the ST-LINK (whereas the other software above does).

I have tried re-installing device drivers (as administrator) but it seems that the CubeProgrammer cannot find my ST-LINK (Nucleo Board) both independently and in Atollic during debug loading. Odd that the firmware upgrade and older program utility work fine.

Can anyone offer any advice on what I should try next?

Thanks, Mark

(Windows 10 LTSB 2016, 14393.2848)

[Clive1 (HNL)]

Make sure the component/dependent DLLs are findable from the location which the application is spawned. That other instances of the application aren't holding a mutex to the hardware/drivers.

[MWill.18]

Hi Clive, thank you for your reply. After days of trying different things, seeing operation of the older utilities but not STMCubeProgrammer I realised I hadn't tried a different USB port.

Moving to direct connection in my laptop allows STMCubeProgrammer to work ok.

Previously the connection for the ST-LINK was:

ST-LINK V2 -> 7-PORT USB 2.0 HUB -> DELL Thunderbolt Docking Station -> Laptop

This did not work with the cube programmer but did allow the driver to enumerate and older utilities to work.

Moving so that the connection is:

ST-LINK V2 -> Laptop

This works with the STMCubeProgrammer!

So after days of hassle, uninstalling, reinstalling, administrator settings, permissions, searching google and forums, trying different applications..... I just needed to use a direct USB port.

That said, with some aspects of the ST-LINK working there must be something in the STMCubeProgrammer that is sensitive to how many hops the USB transfer takes. Perhaps a wait for response that is too short? I have not had any issues with any other USB devices in this configuration.

Odd, but resolved. Hopefully if anyone else has issues, try eliminating docking stations or USB hubs!

Mark

[MWill.18]

Also just tried direct into the Dell Thunderbolt docking station USB ports (eliminating the 7-port hub) and it doesn't work.

Tried a USB hub straight into the laptop and it works.

So it seems the STM32CubeProgrammer doesn't work through my Thunderbolt Docking Station!

[Pavel A.]

@Community member​  Can you try a less ancient WIn10 version? Old versions may have issues with thunderbolt.

-- pa

[MWill.18]

Sadly not as our company issues the LTSB version of windows 10. It gets security and stability improvements but no new features. I will have to stick with using a direct USB port on the laptop.

Mark

[RLebe.1]

I am having the same problem. The IDE works fine but the programmer under Win 10 64 bit and latest Java gives same results.

COne.1798 can you be more specific about your comment: "Make sure the component/dependent DLLs are findable from the location which the application is spawned. "?

-- RL

[Clive1 (HNL)]

An J-Link isn't an ST-LINK, STM32 Cube Programmer doesn't support the former

So the matching DLLs would need to be in the application directory, your current directory, or on the PATH environment list so the tools can locate contemporaneous code to bind against.

[RLebe.1]

OK. So I downloaded Segger 's J-Link commander and successfully updated my probe firmware, erase and load my hex file.

Thanks for the tip. I won't insist with STM32CubeProgrammer.