No ST-LINK detected on STM32F4-Discovery on Arch Linux

[AndrewEmbedded]

I'm trying to work with a STM32F4-Discovery board, and previously it connected perfectly okay, but a couple weeks ago something, seemingly out of nowhere, broke and CubeIDE stopped detecting the board and writing programs to it showing this message:

I tried reinstalling the IDE, downgraging the toolchain, upgrading the IDE, creating a fresh project and so on.

I'm running version 1.19.0 CubeIDE, using EndeavourOS (Arch-based).

Here are my udev rules for a relevant device:

# stm32 nucleo boards, with onboard st/linkv2-1
# ie, STM32F0, STM32F4.

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", \
 MODE="660", GROUP="plugdev", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv2-1_%n"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3752", \
 MODE="660", GROUP="plugdev", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv2-1_%n"

My user is a member of the plugdev group.

 But the important detail is that if I run stm32cubeide_wayland as root through sudo it is able to detect the board. (Still doesn't run the project, but that's because I don't have it setup for root either way.)

Edit:
Here's how it looks when I run stm32cubeide_wayland as root user:

While not root STLinkUpdate gives this:

And trying to run it gives the aforementioned ST-LINK firmware verification.

[Imen.D]

Hello @AndrewEmbedded and welcome to the ST Community,

Check the USB cable or use a different cable (not for charging). 

Try physically reset the board by pressing the reset button.

Check also if the debug pins (SWDIO, SWCLK) are free and reserved for debugging. 

Please follow the tips provided in this article, this may help you:How to solve connection errors when connecting and programming the STM32 target board

[AndrewEmbedded]

I checked multiple cables, none worked on the main system, and the debug pins are free too. As everything works on my work laptop, that's where I continued my work for now, and the exact same cable works on the laptop too.

Hitting reset button didn't help either.

[Ozone]

I can't see anything wrong with your setup. It used to work for me, although different distros.

Perhaps you could try OpenOCD, and check if it sees your ST-Link.
I suppose lsusb lists it correctly.

[AndrewEmbedded]

Yes, lsusb does detect it, as the system in general, it seems to be some strange permission issue.

[mfgkw]

Hello @AndrewEmbedded , maybe (a) the output of dmesg (while connecting the st-link) and (b) long ls output of the devices after connecting could help.

[AndrewEmbedded]

sudo dmesg -W 
[14788.198887] usb 1-2: new high-speed USB device number 14 using xhci_hcd 
[14788.404324] usb 1-2: New USB device found, idVendor=214b, idProduct=7250, bcdDevice= 1.00 
[14788.404333] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 
[14788.404337] usb 1-2: Product: USB2.0 HUB 
[14788.409492] hub 1-2:1.0: USB hub found 
[14788.412309] hub 1-2:1.0: 4 ports detected 
[14788.724908] usb 1-2.1: new full-speed USB device number 15 using xhci_hcd 
[14789.027405] usb 1-2.1: New USB device found, idVendor=0483, idProduct=374b, bcdDevice= 1.00 
[14789.027413] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 
[14789.027416] usb 1-2.1: Product: STM32 STLink 
[14789.027419] usb 1-2.1: Manufacturer: STMicroelectronics 
[14789.027422] usb 1-2.1: SerialNumber: 0668FF505356867767124434 
[14789.112448] usb-storage 1-2.1:1.1: USB Mass Storage device detected 
[14789.112700] scsi host9: usb-storage 1-2.1:1.1 
[14789.124519] cdc_acm 1-2.1:1.2: ttyACM0: USB ACM device 
[14790.168895] scsi 9:0:0:0: Direct-Access     MBED     microcontroller  1.0  PQ: 0 ANSI: 2 
[14790.170507] sd 9:0:0:0: [sdc] 6216 512-byte logical blocks: (3.18 MB/3.04 MiB) 
[14790.170692] sd 9:0:0:0: [sdc] Write Protect is off 
[14790.170699] sd 9:0:0:0: [sdc] Mode Sense: 03 00 00 00 
[14790.170921] sd 9:0:0:0: [sdc] No Caching mode page found 
[14790.170928] sd 9:0:0:0: [sdc] Assuming drive cache: write through 
[14790.199522] sd 9:0:0:0: [sdc] Attached SCSI removable disk

I'm attaching it through a hub, as it worked this way before that.

LANG=es_ES /bin/ls -l /dev/ttyACM0 
crw-rw---- 1 root uucp 166, 0 Oct  6 12:29 /dev/ttyACM0 

[Andrew Neil]

---

@AndrewEmbedded wrote:

I'm attaching it through a hub, as it worked this way before that.

---

Have you tried without the hub ?

And on different physical USB ports?

with a different hub ?

https://community.st.com/t5/stm32-mcus/how-to-solve-debugger-connection-issues/ta-p/49693#:~:text=Try%20other%20USB,be%20quite%20fragile.

 

PS:

---

@AndrewEmbedded wrote:

previously it connected perfectly okay, but a couple weeks ago something, seemingly out of nowhere, broke and CubeIDE stopped detecting the board

---

A recent thread found that their ST-Link connection problem was with insufficient power from the host USB port.

Did you change anything to make the board draw more power ?

[jowakar122]

One of the possibility is that the board is not powered properly. So check the jumpers on the board make sure it gets power from the cable. The jumper should be on ST-LINK.

[AndrewEmbedded]

Assuming this is the jumper you mean, it seems in order.

[rmnmichon]

Any update on this? I'm having exactly the same issue on Arch. Thanks!

[rmnmichon]

Ok, I found a solution that works on my computer. I edited the .rules file so that GROUP is always uucp:

cat 49-stlinkv3.rules 
# stlink-v3 boards (standalone and embedded) in usbloader mode and standard (debug) mode

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374d", \
 MODE="660", GROUP="uucp", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv3loader_%n"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374e", \
 MODE="660", GROUP="uucp", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv3_%n"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374f", \
 MODE="660", GROUP="uucp", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv3_%n"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3753", \
 MODE="660", GROUP="uucp", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv3_%n"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3754", \
 MODE="660", GROUP="uucp", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv3_%n"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3755", \
 MODE="660", GROUP="uucp", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv3loader_%n"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3757", \
 MODE="660", GROUP="uucp", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
 SYMLINK+="stlinkv3_%n"

[timott]

Thanks for providing the solution!

I had the same issue with Fedora 43 and CubeIDE 2.x (newest at the time writing this).

STM32CubeIDE installed as normal user but root/sudo password given during installation.

Debug session worked only when the "ST-LINK_gdbserver" (with its long path) was started using "sudo".

I replaced the GROUP to be "dialout", certainly the "plugdev" was not enough.

Need to dig in bit more, I guess, since the older versions seem to work ok with "plugdev". Apart from OS update

the difference seems to be that plugdev has been create by system (in e.g. Debian) whereas I created it manually

in F43 - this based on the numeric group id (46 in Debian, 1001 in F43). So the issue may be in either OS setup

or CubeIDE (v 2.x) installation - at least in my case.