Arm64 with Snapdragon X plus process unable to detect st link

[PChat.4]

I bought an arm64 based PC a few months ago and I have been unable to connect to or detect stlink even after installing driver, is there a work around? has anyone successfully been able to use the snapdragon processor with stlink? is there another kind of debugger that works with arm based pc's? your help will be highly appreciated, thanks

[Andrew Neil]

What OS are you running on this PC ?

---

@PChat.4 wrote:

 I have been unable to connect to or detect stlink 

---

You mean it doesn't even show up in Device Manager (or equivalent) ?

Have you seen this:

https://community.st.com/t5/stm32-mcus/faq-possible-communication-failure-between-stlink-v3-and-some/ta-p/736578

Also:

https://community.st.com/t5/stm32-mcus/how-to-solve-debugger-connection-issues/tac-p/698105/highlight/true#M956

[Ozone]

OpenOCD is available for Linux, and supports the ST-Link.
I'm pretty sure ARM/ARM64 repositories of most distros provide packages.

As far as Windows for ARM is concerned, you will probably depend on ST to release appropriate drivers.

[PChat.4]

Yeah it doesn't even show up but when I use my old version of PC with an AMD processor it detects the stlink is seconds, is it because arm based pc's are not designed to work with stlink?

[PChat.4]

Totally true I guess my arm pc is useless for debugging hardware

[Ozone]

>... is it because arm based pc's are not designed to work with stlink?

USB is just USB, a serial protocol.
You can try lsusb, and check that your ARM64 device at least lists it.

OpenOCD should come with drivers, and should be available as installable package.
Using Debian/Ubuntu, that would be via apt-get. Other distros user other package management tools.

At least worth a try.

[Andrew Neil]

---

@Ozone wrote:

USB is just USB, a serial protocol.

---

But USB hardware differs.

In particular, there are known problems with more recent PC hardware:

https://community.st.com/t5/stm32-mcus/how-to-solve-debugger-connection-issues/tac-p/698105/highlight/true#M956

(so that would still be nothing to do with CPU architecture)

[Ozone]

> But USB hardware differs.

But that is usually of no concern to the system on the "other side" of the bus.

On the other hand, that there exist faulty USB drivers for certain devices and OSes is nothing new.
In fact, USB drivers are the most common souce of blue-screens under Windows lately. 

And I might remind everybody of the ST-Link V1 device and Windows driver ...

[Andrew Neil]

---

@Ozone wrote:

But that is usually of no concern to the system on the "other side" of the bus.

---

But there are documented issues on the PC side - again, see:

FAQ: Possible communication failure between STLINK-V3 and some recent computers

"While the STLINK-V3 is compliant with USB 2.0 and exhibits reliable USB performance across various platforms since several years, the USB communication may fail between an STLINK-V3 and some recent computers"

There have also been various issues noted with some USB Docking Stations - hence these suggestions:

• Try other USB ports.
• If connecting via a hub, try without it; if connecting without a hub, try with one - a powered one.
• Try connection with no other USB devices - including hubs or "docking stations" - attached.

https://community.st.com/t5/stm32-mcus/how-to-solve-debugger-connection-issues/tac-p/698105/highlight/true#M956:~:text=Try%20other%20USB,docking%20stations%22%20%2D%20attached.

@PChat.4 - have you been through all of these ?

[Ozone]

> But there are documented issues on the PC side - again, see: ...

Yes, correct. Unfortunately. Especially notebooks with their quick model changes rarely receive driver bugfixes and updates.

> Try other USB ports.

Very much corroborated.

Different USB ports, especially those not "side by side", are often connected to different host controllers and thus different drivers or driver instances.

I very well remember times when one had to install the Microchip PICkit driver firmware for every host controller ...