The setup I did:
sudo apt-get install libusb-1.0 libusb-1.0.0-dev
sudo apt-get install cmake
make
cd build/Release/
sudo make install
sudo ldconfig
cat /etc/udev/rules.d/49-stlinkv2.rules
# stm32 discovery boards, with onboard st/linkv2
# ie, STM32L, STM32F4.
# STM32VL has st/linkv1, which is quite different
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", \
MODE:="0666", \
SYMLINK+="stlinkv2_%n"
MODE->0777
md5-85a85af347ad9841fb5f2aa94e96f903
pi@raspberrypi:~ $ st-info --probe
Found 1 stlink programmers
md5-25e2feda051230a3fb7708f4416f9805
pi@raspberrypi:~ $ lsusb -d 0483:3748 -v | grep iSerial
iSerial 3 7ÿpMN85)C
md5-ecdbd20d00e9604653e1b9a039c0ec6d
pi@raspberrypi:~ $ st-info --probe
Found 1 stlink programmers
serial: 303030303030303030303031
openocd: "\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x31"
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0000
descr: unknown device
I think I miss some settings.
Thank you for any help
If you are sure you have access rights and no microcontroller attached it is the normal behaviour you don't get any output. This is currently a limitation of how probe is implemented, you must attach a microcontroller to show detailed information. I have written an experimental project to solve this limitation and probe attached programmers even in the case when no mcu is attached. See: https://github.com/xor-gate/stlink2. I didn't put much effort in the problem to port it back into the texane/stlink project (yet), as it is not as easy as it looks. Still your issue is valid and should be fixed for convience.
OK, thank You for the info but the correct output with data is given on my older image of RPI also with no target attached to programmer(stlink V2 copy). So I assumed I have missed some settings (I am not sure about access rights if everything is OK). I will try your solution also. And I have target attached.
Your tool is working. Thank You
So to summarize, you dont run stlink/stlink2 as root and stlink2 show the expected output with serial of the programmer (and when attached the chipid)?
@xor-gate
same problem.
https://github.com/xor-gate/stlink2
not available.
same problem
on a Gentoo Linux machine
Yesterday the atollicTrueStudio told me that the STLink firmeware on my STM32F411 Nucleo is old and there is an update available
-> OK
then i debugged a part of software ...all works for about 2houres
OK then i disconnected the board,
powered off my PC and today it doesn't work any more
the Program on the Target is still running like charm
BUT
there is no more connection
dmesg
....
[551559.359615] usb 11-4: USB disconnect, device number 6
[551563.688058] usb 11-4: new full-speed USB device number 7 using ohci-pci
[551563.967202] usb 11-4: New USB device found, idVendor=0483, idProduct=374b
[551563.967210] usb 11-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[551563.967214] usb 11-4: Product: STM32 STLink
[551563.967217] usb 11-4: Manufacturer: STMicroelectronics
[551563.967220] usb 11-4: SerialNumber: 066AFF494851877267065831
[551563.969199] usb 11-4: can't set config #1, error -62
...
st-info --probe
setting new configuration (0 -> 1)
Found 1 stlink programmers
serial:
openocd: ""
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0000
descr: unknown device
so it looks like Atollic has, with this update, killed the STLink on my nucleo device :cry: :oops: :evil:
perhaps somebody knows how to fix this problem
same problem
on a Gentoo Linux machine
Yesterday the atollicTrueStudio told me that the STLink firmeware on my STM32F411 Nucleo is old and there is an update available
-> OKthen i debugged a part of software ...all works for about 2houres
OK then i disconnected the board,
powered off my PC and today it doesn't work any more
the Program on the Target is still running like charm
BUT
there is no more connectiondmesg .... [551559.359615] usb 11-4: USB disconnect, device number 6 [551563.688058] usb 11-4: new full-speed USB device number 7 using ohci-pci [551563.967202] usb 11-4: New USB device found, idVendor=0483, idProduct=374b [551563.967210] usb 11-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [551563.967214] usb 11-4: Product: STM32 STLink [551563.967217] usb 11-4: Manufacturer: STMicroelectronics [551563.967220] usb 11-4: SerialNumber: 066AFF494851877267065831 [551563.969199] usb 11-4: can't set config #1, error -62 ...
st-info --probe setting new configuration (0 -> 1) Found 1 stlink programmers serial: openocd: "" flash: 0 (pagesize: 0) sram: 0 chipid: 0x0000 descr: unknown device
so it looks like Atollic has, with this update, killed the STLink on my nucleo device 😢 :oops: :evil:
perhaps somebody knows how to fix this problem
Same problem with rebooting MacBook.
@lkord @artbody @RockyF: What st-link version are we talking of? We need more details here on build environments and hardware.
XNUCLEO-F103RB here, and the same symptoms. Firmware upgrade and now chip id shows 0000 for the thing.
@ all: Please make sure you report all your software and hardware info:
Debian Unstable
Package: stlink-tools
Version: 1.6.0+ds-1
I think this is st-link/v2 programmer, it was bundled with the xnucleo board. I am extremely new to this =). Maybe this is relevant:
[637361.699535] usb 1-1: new full-speed USB device number 56 using xhci_hcd
[637361.848669] usb 1-1: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00
[637361.848670] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[637361.848671] usb 1-1: Product: STM32 STLink
[637361.848671] usb 1-1: Manufacturer: STMicroelectronics
[637361.848672] usb 1-1: SerialNumber: QÿkxfVS34g
For anybody else possibly googling this. I happened to have a copy of the original board firmware ad a .bin file and managed to get it back working by putting a jumper on CN7 pins 5-7 and then running st-flash writing the original firmware to the board.
@jpesonen-priv: ok, good, but that still does not give any idea on why this happened (which is the relevant point to us)...
@Nightwalker-87 I can reproduce this too by flashing anything with the STM32CubeIDE to the board, but I don't know what is and how to get information relevant to you.
As it reads, @lkord was able to rule out that the st-link tools were source of this problem.
The findings of @artbody, @RockyF and @jpesonen-priv seem to be a different problem.
Here it looks like as if a corrupted firmware image has been loaded to the programmer, what resulted in the same output on st-info --probe
. This appears to be not related to the stlink-tools, so that we can't provide any support here, apart from suggesting to look for a newer genuine firmware revision for the used programmer and to verify a downloaded firmware-file by a checksum. If no newer firmware is available, one would have to reload the original one, as explained above.
Thx for the helpful feedback @jpesonen-priv which now allows to close this ticket with a solution. :+1: