stlink: STM32F100RBT6: Failed to read core_id and unknown device

Yeah, I think we have seen enough resulting output by now - time to investigate the cause. 😉

@petertorelli: Ok, but can you review the current state of STLINK/V1 device handling with libusb? I saw that you dealt with such problems before in the codebase. We have at least two people here with the right hardware to assist with testing and can provide feedback - this shouldn’t be an issue.

I have both Mint Linux (20.1) machine and Windows 10 machine to do testing on the following boards:

1. STM32VLDISCOVERY (STM32F100RB) using ST-LINK-V1
2. STM32F4DISCOVERY (STM32F407VG) using ST-LINK/V2-A
3. NUCLEO-F103RB (STM32F103RB) using ST-LINK-V2-1
4. NUCLEO-F446RE (STM32F446RE) using ST-LINK/V2-1
5. NUCLEO-L433RC-P (STM32L433RC-P) using ST-LINK/V2-1
6. NUCLEO-F302R8 (STM32F302R8) using ST-LINK/V2-1
7. NUCLEO-F767ZI (STM32F767ZI) using ST-LINK/V2-1

I also own an ST-LINK-V2 device and ST-LINK-V3 device and various ST-LINK-V2 clones

just let me know what you want me to test.

Found 1 stlink programmers version: V1J13 serial: 553f6d06483f48534641213f

Launch it a second time, see where the Found 1 stlink programmers version: V1J13 serial: 553f6d06483f48534641213f goes…

Hi guys! Thanks for your effort!! As I’ve found a couple of the VL boards in my junkbox I’ve tried with 1.6.1 and I’ve ran into the same issues as described above - with latest Lubuntu 20.04. (Btw the 1.6.1 flashes with the Discovery F407 board, but not reliable enough - sometimes it flashes ok, sometimes not…) I’ve done the 1.6.0 install as described above by GadgetAngel and the flashing of my VL board now works.

I am getting the same problem with my STM32VLDISCOVERY board. ST-LINK V1 is detected by Linux Mint 20.1 but st-util does not work or st-info does not read the chip info correctly.

EDIT: I did the following to get it to work:

cd /usr/local/lib
sudo rm -fr all libstlink*
rm ~/Repo/stlink/*.*
rmdir ~/Repo/stlink
git clone -b v1.6.0 https://github.com/stlink-org/stlink.git

make clean
make release
cd build/Release && sudo make install
sudo ldconfig
// the udev rules files are still in place
// the /etc/modprobe.d file is still in place for /etc/modprobe.d/stlink_v1.conf
sudo udevadm control --reload-rules
sudo udevadm trigger
reboot the system

Something in v1.6.1 has broken stlink-v1 from working. But I does work if you roll back to V1.6.0

Hi, thanks for your comments.

The solution I’ve found to satisfy my needs, and couldn’t be too hard to follow for disatisfied StLink v1/ VL owners, who are trying to use it under Linux, as a workaround until the developer/s find a time frame to tackle this 😃 But I agree, the stlink-download.c is a rigmarole, but a rigmarole I mentioned only just in case it could give you a hint. I mean, why executing it allows the st-info utility to get the right values afterwards? (but no flashing works until you delete current libs and replace it with 1.6.0’s as I said…) Does this give you a bit of a hint, even if only by intuition?

I guess I can try and compare/ track/ debug by myself the actual calls, parameters and execution of the current 1.6.x against the “bad” libraries versus the 1.6.0 versions, as it seems pretty obvious the differences couldn’t be due to differing interfaces or something, so I’m almost sure this has to be some subtle quirk we’ve / you’ve not yet found.

If I make some advance on this of course I’ll let people now here.

LD3 and LD4 are the leds you may let blink with the Blink demo (arduino with stm32 support installed). The leds are called LED_BLUE and LED_GREEN inside arduino IDE then (with the DiscoveryVL board selected). The default LED in the Blink sketch is named “LED_BUILTIN” thus you will not see the led blinking with the default…

@Nightwalker-87 pong: Unfortunately I do not have any L100 series boards, so I cannot reproduce the issue.

Usually one can simply copy console output as is and paste it and use < > afterwards to define a codeblock formatting around it. However, note that there also is www.pastebin.com for complete console outputs.

After firing up the Lubuntu (with stlink connected) and entering the sudo st-info --probe I get the same Found 0 stick inormation as you got… I plugged the stlink off/on and:

me@lub:~$ st-flash write /tmp/arduino_build_504102/Fade1.ino.bin 0x08000000
st-flash 1.6.0
2021-03-09T18:43:28 INFO common.c: Loading device parameters....
2021-03-09T18:43:28 INFO common.c: Device connected is: F1 Medium/Low-density Value Line device, id 0x10016420
2021-03-09T18:43:28 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2021-03-09T18:43:28 INFO common.c: Attempting to write 15416 (0x3c38) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003c00 erased
2021-03-09T18:43:29 INFO common.c: Finished erasing 16 pages of 1024 (0x400) bytes
2021-03-09T18:43:29 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2021-03-09T18:43:29 INFO flash_loader.c: Successfully loaded flash loader in sram
 16/16 pages written
2021-03-09T18:43:30 INFO common.c: Starting verification of write complete
2021-03-09T18:43:30 INFO common.c: Flash written and verified! jolly good!
me@lub:~$ 

PS: Btw I still get “Found 0 stlink programmers”, even it flashes the binary into F100 fine…

Have the same problem. Checked with version from repository community/stlink 1.6.1-1 and latest develop branch. Board - STM32VLDISCOVERY

Linux i5 5.4.61-rt37-MANJARO #1 SMP PREEMPT_RT Sat Aug 29 17:09:34 UTC 2020 x86_64 GNU/Linux
core/libusb 1.0.23-2
extra/libusb-compat 0.1.7-1

Latest working commit: e3aa887f7ffdfcfb3a0529ee3b94a7d3fe39b5d8