Stlink: STM32F100RBT6: Failed to read core_id and unknown device

[WK-M]

Thank you for giving feedback to the stlink project.

NOTICE: Please read and follow instructions in #906 before submitting a ticket. This feature request will be deleted without notice when not enough information is provided! So please ensure that all fields are filled out.

• [x] I made serious effort to avoid creating duplicate or nearly similar issue

In order to allow developers and other contributors to isolate and target your respective issue, please take some time to fill out each of the following items appropriate to your specific problem:

• Programmer/board type: Onboard STLINK/V1
• Operating system and version: Fedora 32
• Stlink tools version and/or git commit hash: v1.6.1
• Stlink commandline tool name: st-info and st-util
• Target chip (and board if applicable): STM32F100RBT6

Futher we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:

Commandline-Output:

For st-util:

st-util -1
st-util: invalid option -- '1'
st-util
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_GET_VERSION
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_GET_CURRENT_MODE
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_GET_CURRENT_MODE
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_ENTER
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_RESETSYS
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_READCOREID
2020-10-05T03:31:27 ERROR common.c: Failed to read core_id
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2020-10-05T03:31:27 WARN common.c: Invalid flash type, please check device declaration
2020-10-05T03:31:27 ERROR gdb-server.c: Unsupported Target (Chip ID is 0000000000, Core ID is 0000000000).

For st-info:

[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_GET_VERSION
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_GET_CURRENT_MODE
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_GET_CURRENT_MODE
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_ENTER
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_RESETSYS
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_READCOREID
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
Found 1 stlink programmers
 serial:     303030303030303030303031
 hla-serial: "\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x31"
 flash:      0 (pagesize: 0)
 sram:       0
 chipid:     0x0000
 descr:      unknown device

Expected/description:

The device should not be read as an unknown device when executing st-info --probe, and there should not be a gdb-server error when running st-util. However, the board is able to be detected when running lsusb.

Bus 001 Device 013: ID 0483:3744 STMicroelectronics ST-LINK/V1

I'm still relatively new to STM32 and ARM, please let me know if there's any other details that I can provide.

Thank you for your support.

The stlink project maintainers

[Nightwalker-87]

Thx for reporting. I can verify this with my STM32VL Discovery board that comes with this chip.

[corecell]

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

[Ant-ON]

How I wrote in stlinkV3 issue: it patch may break v1 support ( https://github.com/stlink-org/stlink/issues/820#issuecomment-617591438 )

@WK-M Can you try patch to develop branch:

index 9726ddc..a683267 100644
--- a/src/stlink-lib/usb.c
+++ b/src/stlink-lib/usb.c
@@ -261,7 +261,10 @@ int _stlink_usb_write_debug32(stlink_t *sl, uint32_t addr, uint32_t data) {
 }

 int _stlink_usb_get_rw_status(stlink_t *sl) {
-    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { return(-1); }
+    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { 
+        /* STLINK does not support getting statuses. Returns the IO operation is success */
+        return 0;
+    }

     unsigned char* const rdata = sl->q_buf;
     struct stlink_libusb * const slu = sl->backend_data;
@@ -300,7 +303,7 @@ int _stlink_usb_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {

     if (ret == -1) { return(ret); }

-    ret = send_only(slu, 0, data, len);
+    ret = send_only(slu, 1, data, len);

     if (ret == -1) { return(ret); }

[WK-M]

How I wrote in stlinkV3 issue: it patch may break v1 support ( #820 (comment) )

@WK-M Can you try patch to develop branch:

index 9726ddc..a683267 100644
--- a/src/stlink-lib/usb.c
+++ b/src/stlink-lib/usb.c
@@ -261,7 +261,10 @@ int _stlink_usb_write_debug32(stlink_t *sl, uint32_t addr, uint32_t data) {
 }

 int _stlink_usb_get_rw_status(stlink_t *sl) {
-    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { return(-1); }
+    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { 
+        /* STLINK does not support getting statuses. Returns the IO operation is success */
+        return 0;
+    }

     unsigned char* const rdata = sl->q_buf;
     struct stlink_libusb * const slu = sl->backend_data;
@@ -300,7 +303,7 @@ int _stlink_usb_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {

     if (ret == -1) { return(ret); }

-    ret = send_only(slu, 0, data, len);
+    ret = send_only(slu, 1, data, len);

     if (ret == -1) { return(ret); }

When you state "patch to develop branch", did you want me to checkout to the develop branch and attempt the same commands? If that is not what you meant, please let me know.

Otherwise, I have performed the checkout to the develop branch and performed the proper reinstallation. I am still running into the same errors mentioned in the original posting.

[Ant-ON]

@WK-M I apply patch to new branch https://github.com/Ant-ON/stlink/tree/try_fix_stlinkv1. Try clone try_fix_stlinkv1 branch and build stlink tool from source.

[WK-M]

Thanks for the clarification. I cloned the patch, and I'm still running into the same issues.

I'm not sure if this is a Fedora-specific issue as I am not running into the same error on my Ubuntu machine.

[Nightwalker-87]

@Vascom Any idea regarding Fedora? It looks like an issue with libusb.
@WK-M which version of libusb do you use. Have you tried to reinstall or update it?

[Vascom]

F32 use libusbx-1.0.23.
Which version at ubuntu?

[WK-M]

Sorry for the late response.

From the command: dpkg -l libusb-1.0*, I got the following:

+++-======================-================-============-===================================================
ii  libusb-1.0-0:amd64     2:1.0.23-2build1 amd64        userspace USB programming library
ii  libusb-1.0-0-dev:amd64 2:1.0.23-2build1 amd64        userspace USB programming library development files

[mosagepa]

Is this being tackled, any advance?
I didn’t see the id for this on announce for 1.6.2 still, yet of course thanks to all the efforts by developers.
I myself have same issue, on VL Discovery, I’m on the road but will post my details later on. Ubuntu 16.04LTS fresh box, yeah I love kinda retro! ....
Gave it a try, remember stlink-download.c posted somewhere else? (Fiddled with this code to see whether the 0’s were from other strange bug, but I have also the feeling that libusb is to blame...)
Regards

[mosagepa]

I update.
Everything is working now for my VL Discovery.
Using Ubuntu 16.04LTS kernel 4.15.18-041518-generic.
Libusb-0.1.4 (2:0.1.12-28) both :amd and :i386, and
Libusb-1.0.0 (2:1.0.20-1) both :amd and :i386 are installed on this machine acording to ‘dpkg -l libusb’ output
(I guess this is because for other problems I had before, not related to STLink, I did a lot of recompiling and version trying for libusb in the past, can’t recall exactly now...)
(Also correct me if I could be wrong, but I don’t think the coexistance of i386 versions makes a difference to this reported problem.)
Anyway, this is what worked for me:
I just had to rm -fr all libstlink under /usr/local/lib,
Then proceed to recompile stlink from 1.6.0 tree I had in backup.
Maybe this can shed some light also:
I had noticed previously that invoking ‘stlink-download /dev/stlinkv1-1 info’ just after connecting the VL to the USB port, and then invoking ‘stlink-gui’ the Stlink-gui let me query the device and yielded the Value Line id and chipid without any problem, and then afterwards also ‘st-info —probe’ gave out the right values, but then any debug session in gdb didn’t get to load into SRAM the flash routine to erase, and it failed...
Also, if I proceed to launch ‘st-info -probe’ right after plugging the USB,it didn’t work, I always had to launch ‘stlink-download’ (even if it failed itself) for both ‘stlink-gui’ and ‘st-info —probe’ to yield the right ID values from that moment on... quite strange, it seems as if the stlink-download executable makes casually for some not so ovbious internal change in VL that gets it right (mostly) afterwards.
This experiment could maybe give some hint to the developers about what could be the issue underneath... I hope so!
Anyway, as I said the fix for me was as I mentioned, to wipe old/conflicting libs and recompile BUT use 1.6.0. You maybe want to make sure also, to do a ‘sudo ldconfig’ afterwards just in case.
Btw, the aforementioned ‘stlink-download’ is to be found under:
https://github.com/vanbwodonk/arm-utilities/blob/master/stlink-download/stlink-download.c
(This site seems to maintain also a v2 consolidated version. Any of those two is clarifying -see comments within the C code- as of the deeply broken nature of the ST-Link/V1 scsi-based coding...)
I really can’t fathom why the ST engineers opted for that unorthodox way of communicating with the F103 chip... this is as cheesy a programming firmware job as I’ve ever seen... I guess they deserve the firmware “decrypting” notices they had to suffer from a bunch of hobbyist out there, deserved punishment IMHO ;)
So, I am now finally happy and GDB-ing all the way in Linux with my VL Discovery.
I got so happy, I ordered TWO more of this board, for just $15 apiece, the two finals in stock there were from some distributor. Go figure out! I really hate programmed obsolescence, so I tend to get quite happy when I resurrect deprecated hardware for all things uC-related, specially if it’s on Linux!

[Nightwalker-87]

Libusb-0.1.x is not used and thus not needed by this toolset.
@mosagepa This looks way to complicated to serve as a common solution.

I have a STM32F100RBT6 (VL Discovery) with STLINK-V1 as well, but unfortunately had no time to run any tests yet besides professional work...

[mosagepa]

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.

[mosagepa]

New update:
I've noticed that, even with the libraries "purged" as I commented above, first call to 'st-info --probe' yields out a significant (and different but consistent for any one of my 3 VL Discoveries) serial number, just after plugging them to USB port, BUT as soon as you relaunch 'st-info --probe' the model is correctly detected still as Value Line F1xxx blah blah... BUT, yields now 0x30 0x30 0x30..... i.e. all zeroes chain as "serial".
So maybe this gives me a clue to debug what is really happening here, hopefully I can trace the "bug" (or problem) down to its origin following the inner calls in the 'st-info' execution.
I am being stubborn in this just because I'd like the VL Discovery not to get into forever oblivion but to end up having proper "support" under Linux, so I guess any help in this regard can be appreciated by a bunch of people using VLs if yet a minority I know...

[mosagepa]

I wish to add (and yeah I know this is not a Forum but anyway...) I had once a friend which works designing firmwares and products for automotive products with NXP chips, objecting to my dwelling and obfuscations over "End-Of-Life" products, his reasoning was, the development boards and kits have the lifespan of flies, serving only their purpose while the HW guys are figuring out the final board but the SW/FW guys should be developing the support code anyway even with the prototypes.
So when a new "line" is launched by the chip/uC manufacturers, they (the companies manufacturing real stuff) obligue to buy the development kits in order to be quicker than their competitors launching their new-line-based final product.
Meaning, any hobbyist using (or resurrecting, as I tend to do) older deprecated platforms, and buying these obsolete kits 2nd hand, were making fools of themselves.
I understand, but can't be happy conforming to such reasoning, and that's why I am so stubborn with this and many other abandonware HW/FW stuff for uCs. I have the same respect for people who insist on using say, 16F84 PICs just because they want to (or can't afford anything "fancier"). So same story with STM32 neverending improving lines and kits: I hope some other soul/s there still want to use the VL Discovery in projects, or just for plain fun, and can benefit from any advance on this issue. But I digress...

[GadgetAngel]

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

[mosagepa]

Exactly same approach I used, @GadgetAngel Congratulations!
I am trying to get a bit of hold of other work occupations in order to track down what exactly are the differences between 1.6.0 and 1.6.1.

Please can you confirm if you face this also (I copy here the fragment of previous post):

_- "I've noticed that, even with the libraries "purged" as I commented above, first call to 'st-info --probe' yields out a significant (and different but consistent for any one of my 3 VL Discoveries) serial number, just after plugging them to USB port, BUT as soon as you relaunch 'st-info --probe' the model is correctly detected still as Value Line F1xxx blah blah... BUT, yields now 0x30 0x30 0x30..... i.e. all zeroes chain as "serial"._

_