STM32F100RBT6: Failed to read core_id and unknown device

[WK-Kz]

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-Kz]

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-Kz]

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-Kz]

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".

_

[igor-m]

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.

[GadgetAngel]

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".

_

I honestly cannot remember what the output was when I had the error.

What I do know is the V1.6.0 is more reliable for me and I can use it on many different boards {VL discovery, F4 discovery, NUCLEO board}

[Nightwalker-87]

As I was able to verify with the same board, this regression is still present in the current develop branch.

Further investigation confirms that v1.6.1 does not run properly after a clean install and locks-up the programmer:

 sudo st-info --probe
[!] send_recv read reply 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:     553f6d06483f48534641213f
 hla-serial: "\x55\x3f\x6d\x06\x48\x3f\x48\x53\x46\x41\x21\x3f"
 flash:      0 (pagesize: 0)
 sram:       0
 chipid:     0x0f29

[Nightwalker-87]

Following the approach from @GadgetAngel on v1.6.0 unfortunately does not recover my STM32VLDiscovery board, though it seems to have helped others. The programmer is simply not detected any more:

sudo st-info --probe
Found 0 stlink programmers

Knowing there are several other bugs in v1.6.0, one should focus on the current develop branch in order to resolve this properly. I'd love to see the STLink/v1 working and ensure continued support by this hardware though only few people still seem to use it.

[igor-m]

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..

[igor-m]

me@lub:~$ st-info
st-info --version
st-info --flash
st-info --sram
st-info --descr
st-info --pagesize
st-info --chipid
st-info --serial
st-info --hla-serial
st-info --probe
me@lub:~$ st-info --flash
0x20000
me@lub:~$ st-info --version
v1.6.0
me@lub:~$ st-info --chipid
0x0420
me@lub:~$ st-info --hla-serial
""
me@lub:~$ st-info --descr
F1 Medium/Low-density Value Line device
me@lub:~$ st-info --flash
0x20000
me@lub:~$ st-info --sram
0x2000
me@lub:~$ st-info --serial

me@lub:~$ st-info --probe
Found 0 stlink programmers
me@lub:~$ 

[Nightwalker-87]

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

[mosagepa]

Woah, what a change. I was contributing to this very same issue, along with @GadgetAngel, but somehow @Nightwalker-87 didn't allow me to post more follow-ups to this. (That's at least what it looked like from what the forum engine was telling me, "an admin has disabled the ability to post if you posted previously" or similar rigmarole...) I know the exact cure for this issue -at least for my Ubuntu 16.04 LTS setup- BUT I don't think people harassing other people's advances (even if it means going back to v1.6.0) would help anyone. For me a couple of README.TXTs written down by myself with the intricate details to make it work, deep down in my computers somehow can work better than tons of GitHub pulls and requests... Still, as these follow-ups show, there's enough demand for ST-Link v1 in the VL Discoveries to merit investigation. Too sad the manners here are such that they need such evidence to fix things up even WITH people wanting to contribute. All I know I got my three VL Discoveries working nicely right now (yeah, I got two more of those... come to think of it, when people got fed up of trying to fix the damn thingies, they suddenly dropped in price, I can't complain about that :)

[Nightwalker-87]

Aha, interesting, let me have a closer look at this message... That's not intended. - Could have been the result of a temporary limitation though upon frequent opening of issues by some single individuals that don't seem to be able to respect any project guidelines. Currently there are no general limitations.

[Nightwalker-87]

@mosagepa: Please feel free to share your findings. In fact we need a fix for the current develop tree. Going back in time is not a satisfiable solution, apart from locating fixes from the past.

[Nightwalker-87]

However to be honest, I can vaguely remember that I had my board running with this toolset in the past, though I have not been using it for quite a long time...

@Ant-ON: It would be very kind if you could help to restore a working state or at least unravel the specific changes you made to locate the actual issue.

[mosagepa]

@mosagepa: Please feel free to share your findings. In fact we need a fix for the current develop tree. Going back in time is not a satisfiable solution, apart from locating fixes from the past.

That's ok, I was just in a bad mood yesterday I guess. I don't know what the limitation was about (could be my non-terse style or my multiple edits back then), but it's now removed. Sorry for the lengthy posts, I know this is not a forum.

To focus on feasible solutions, I don't know if this could be fixed in v1.6.1 onward since I didn't write the code so I don't know, what could possibly have gone "wrong"?

For me going back to v1.6.0 fixed it, but of course one must consider the dreaded libusb/ Python/ libc/ issues in a quite deprecated 16.04 Ubuntu like mine (horribly beaten after multiple problems...)

If you read my previous posts there were an alternative command line utility in some other site:

stlink-download utility source

To quote the interesting "comment" within that code: Usage notes: This is a deeply broken device. They apparently built the mass storage interface by cribbing the USB device table from a 32MB flash stick. But the device doesn't have 32MB, only hard-wired responses that presents three tiny 'files'. Not arbitrary responses, only ones to the exact USB commands that Windows would use, and only accurately filling in the fields that Windows uses. The result is that non-Windows machines choke on this device. (It's likely that future Windows versions will as well.) Linux automatically checks the partition table and validates the extents. It takes several minutes of periodic retries before the kernel gives up and decides it is truly broken.

The emulation of some SCSI interfaces to a "drive" is more or less the same approach used to convenient download in most recent ST Discoveries e.g. F40x series, but in ST Link v1 the "faked SCSI device/ drive" was used also for communicating with the firmware, commands and all that.) I can't get why on earth did they do this (ST engineers).

It is not fully clear to me: 1) whether "Linux automatically checks the partition table and validates the extents" means we have to live with this or could be somehow bypassed for VL Discoveries (if that's the real cause); 2) why one must use such code when the author warns that we should wait for a few minutes to get the kernel to give up on the SCSI issue before we can begin to really use the VL; 3) whether "only ones to the exact USB commands that Windows would use, and only accurately filling in the fields that Windows uses" could give as a hint as to how to properly fake the VL, i.e. making it see the same "fields" used in the (working) Windows setups.

In any case, I don't think this path leads to anywhere for us. Since most advice out there depends on explicitly disabling the SCSI "drive" even showing up as storage device (hey, I too like my 'dmesg' crisp and tidy!) the above C code is just useless for us. We shouldn't need to wait for minutes for the kernel to give up.

(Updated: please see and try my own test code in my other post down below...)

Furthermore, there must be clearly some interaction with such "device mode", as it was the v1 series only which did this, new implementations/ interfaces of libusb+some quirk/s on v1.6.1+ makes the implementation become not "retro compatible"...

All this is talking in general terms, of course we need to dig down the calls and all that. Since I don't know my way too well around libusb, debugging means nitpicking the code to death with custom printfs and all that. About my writing and documenting style (unorthodox by technical/ programming standards) hey, I just learnt how to use some git commands days before, don't be too harsh on me!

While I was investigating these issues, I happened to find other solutions which could apply to some of us. Like faking the VL to pretend to be a JLink and things like that (flashing a modded JLink-like firmware, all legal don't worry). But I am too stubborn to be content with such workarounds. I wanted to fully use my VL Discovery with stlink in my patched-up dead horse 16.04 LTS Ubuntu.

[mosagepa]

This is also to let you know I've written a bit of mixed up code which if you execute will let all you test whether your VL Discovery can be detected (fully, means: meaningful serial and all that).

The differences wrt to stlink's way / sequence / parameters when doing the same calls could give any hints to the developers. They must know what I'm talking about: the encapsulations used by stlink might make it hard to correlate its code to "my" code, but I think we'd be on our way by just doing that.

I encourage all folks having problems with their VL's to please copy up the code, and report your findings. I myself compiled it with this precise command line: g++ -o tryMosa02 tryMosa02.cpp -I /usr/local/include/libusb-1.0 -L/usr/local/lib -lusb-1.0

I'd advise to put the -lusb* switch last in the command, I've seen some setups where it won't work in any other place. For reference, my /usr/local/lib/libusb* are as follows (your command line and libs mileage may vary, but that's one of our challengues, to identify which configurations work and which don't...):

lrwxrwxrwx 1 root root     19 abr 26  2020 /usr/local/lib/libusb-0.1.so.4 -> libusb-0.1.so.4.4.4
-rwxr-xr-x 1 root root 110472 abr 26  2020 /usr/local/lib/libusb-0.1.so.4.4.4
-rw-r--r-- 1 root root 851222 feb  3 15:46 /usr/local/lib/libusb-1.0.a
-rwxr-xr-x 1 root root    980 feb  3 15:46 /usr/local/lib/libusb-1.0.la
lrwxrwxrwx 1 root root     19 feb  3 15:46 /usr/local/lib/libusb-1.0.so -> libusb-1.0.so.0.2.0
lrwxrwxrwx 1 root root     19 feb  3 15:46 /usr/local/lib/libusb-1.0.so.0 -> libusb-1.0.so.0.2.0
-rwxr-xr-x 1 root root 502144 feb  3 15:46 /usr/local/lib/libusb-1.0.so.0.2.0
-rwxr-xr-x 1 root root    795 abr 26  2020 /usr/local/lib/libusb.la.backup
lrwxrwxrwx 1 root root     21 abr 26  2020 /usr/local/lib/libusbpp-0.1.so.4 -> libusbpp-0.1.so.4.4.4
-rwxr-xr-x 1 root root 201664 abr 26  2020 /usr/local/lib/libusbpp-0.1.so.4.4.4
-rw-r--r-- 1 root root 385884 abr 26  2020 /usr/local/lib/libusbpp.a
-rwxr-xr-x 1 root root    834 abr 26  2020 /usr/local/lib/libusbpp.la
lrwxrwxrwx 1 root root     21 abr 26  2020 /usr/local/lib/libusbpp.so -> libusbpp-0.1.so.4.4.4
lrwxrwxrwx 1 root root     19 abr 26  2020 /usr/local/lib/libusb.so -> libusb-0.1.so.4.4.4

For me this simple code works like a charm. This may be due just to it explicitly using and linking to libusb-1.0, not the 0.x that comes prepackaged with many a Ubuntu, though. When I say "like a charm" I mean: 1) displaying the real, meaningful "serial" for your VL 2) consistently doing 1) across multiple executions, since one of the reported problems was that, sometimes even when displaying "right" serial, the next time you access the VL it goes bananas again.

tryMosa02.cpp.gz

[Nightwalker-87]

I can give you the console output for e.g. b47f083736a6f6137e317e70998501205d44265f :

st-info --probe
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
[!] 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
  version:    V1J13
  serial:     553f6d06483f48534641213f
  hla-serial: "\x55\x3f\x6d\x06\x48\x3f\x48\x53\x46\x41\x21\x3f"
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x0000
  descr:      unknown device

st-flash write /[...]/Blinker.bin 0x8000000
st-flash 1.6.1-135-gb47f083
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
[!] 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
2021-03-10T09:32:04 ERROR common.c: Failed to read core_id
[!] send_recv send request failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2021-03-10T09:32:04 WARN common.c: Invalid flash type, please check device declaration
Failed to connect to target

... and the device locks up with the COM LED switching to the on-state, so I assume this is related to libusb device handling.

Looking at the output, I find the device serial not to be the problem at this point, but as we have found out in #356, some general problems regarding codebase-compatibility seem to have silently occurred between master and develop without notice (e.g. build errors that could be detected by our CI service). We need to bring both branches to the same common base before trying to solve anything. Maybe it's about time for a new release including all other fixes from develop well knowing there are still bugs like this one to be solved, but we can include this in the release note and ask everybody only to work with that new release as a common base for investigation. Any other ideas on that?

[mosagepa]

My current "idea" is that using stlink even in v1.6.0 I can go on this "second call error" serial issue forever: mosagepa@MProLinux:~/decomp/STM32/oldLinuxSTLink/withSTLink$ st-info --probe Found 1 stlink programmers serial: 393f6f064d42343816512543 hla-serial: "\x39\x3f\x6f\x06\x4d\x42\x34\x38\x16\x51\x25\x43" flash: 131072 (pagesize: 1024) sram: 8192 chipid: 0x0420 descr: F1xx Value Line mosagepa@MProLinux:~/decomp/STM32/oldLinuxSTLink/withSTLink$ st-info --probe Found 1 stlink programmers serial: 303030303030303030303031 hla-serial: "\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x31" flash: 131072 (pagesize: 1024) sram: 8192 chipid: 0x0420 descr: F1xx Value Line mosagepa@MProLinux:~/decomp/STM32/oldLinuxSTLink/withSTLink$ and so on and on...

Compare this to my code execution (have you tried already?). You can launch my code a zillion times, it will always return the right, meaningful serial.

I appreciate your codebase maintenance workforce, but I guess something very very subtle is happening in the translation so to speak between your encapsulations and the pure libusb calls (again, correlate your code with my libusb-only code).

I used to think that libusb was the culprit, but now I am pretty sure the detail is very subtle and hidden somewhere, yeah, and we all know it might be easier fixed than located :)

[mosagepa]

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...

[mosagepa]

You say "Looking at the output, I find the device serial not to be the problem at this point, "

But I insist on the serial issue just because it's the hint that something is not going right in the libusb calls within stlink's encapsulation.

[mosagepa]

Please try to re-code st-link, especifically the --probe switch in the code. I have a feeling the problem comes with the specific sequence of libusb calls made (and maybe already made before?) within where the user calls with that argument before doing anything else with st-link. You never know the side effects to some detection/ probing double calls to libusb. Just my two cents worth (I don't know what the code does at a deep level, just talking from memory some days ago in February where I was trying to diagnose it...) Also PLEASE read my posted code above, especially this bit:

(...)

int temppo = libusb_get_string_descriptor_ascii(dev_handle, 2, myRcvStr, 64);

cout<<"The device's descriptor (ASCII form) for index 2 is \""<<myRcvStr<<"\","<<endl;

temppo = libusb_get_string_descriptor_ascii(dev_handle, 3, myRcvStr, 64);

because I have a feeling that stlink with the --probe option goes looking out for the wrong indexes !!! If you do it wrong, you get the serial FOR THE USB STORAGE part, which is (oh my 000000...01 where have I seen this before? hint: 0x30303030303030....31 ...)

[Nightwalker-87]

@mosagepa: "at this point" solely referred to the used commit. I have not systematically tested the other (especially earlier versions). I'd consider it a good idea if people who coded in this part more recently have a look at this. Quite a few parts in the codebase don't have sufficient documentation which of course does not facilitate understanding of what is happening here exactly.

[mosagepa]

Please ask them to have a look at indexes accessed during probing. If you get the indexes wrong, it refers to the wrong USB sub-device which is basically the broken USB storage part which Linux users couldn't care less about (for the VL case). So any libusb calls made after the first invocation of st-util --probe from a fresh (namely that just got connected to the USB port) goes bad too.

[Nightwalker-87]

Ping @grevaillot @rewolff @petertorelli

[Ant-ON]

@mosagepa @Nightwalker-87 Can you try get log after change line?

https://github.com/stlink-org/stlink/blob/8429ac078a783ee6d75db6bd8741eba732959c54/src/st-info/info.c#L88 to

    sl = stlink_v1_open(DEBUG_LOG_LEVEL, 1);

Although stlink_v1_open hasn't been used in st-flash for a long time... See https://github.com/stlink-org/stlink/commit/fc507fd4842cd9b4719378d0ee79a6a123eecae3

[Nightwalker-87]

error: ‘DEBUG_LOG_LEVEL’ undeclared (first use in this function) 97 | sl = stlink_v1_open(DEBUG_LOG_LEVEL, 1); :-1:

[Ant-ON]

@Nightwalker-87 use 100 instead DEBUG_LOG_LEVEL

[Nightwalker-87]

It compiles, but produces same output as posted earlier. We should better not try and error here - one needs to understand what is happening and where to look at exactly.

I'll have to put this aside for now to deal with some other issues as long as I have the chance to fix stuff and do some maintenance for a few days. I certainly do what I can, but can't help the fact that there aren't enough developers around that address advanced tasks regularly. :disappointed:

[mosagepa]

It must be LIBUSB_LOG_LEVEL_INFO maybe? (suggested to me by the compiler).

Anyway, on first execution from just connected VL I get:

[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
[!] 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
  version:    V1J13
  serial:     393f6f064d42343816512543
  hla-serial: "\x39\x3f\x6f\x06\x4d\x42\x34\x38\x16\x51\x25\x43"
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x0000
  descr:      unknown device

and that's surely the "good" serial BUT you see the chipid zero'd and something goes wrong, the lights on VL get both RED leds on (but it's apparently still executing my previously flashed blinky on the GREEN one), whereas on second and further executions afterwards not even the serial is given out right, it gets the wrong "interface", "device" or whatever personality which is the STM32 Mass Storage broken "index", with serial 00000...1:

[!] 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_JTAG_READDEBUG_32BIT
[!] 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
  version:    V1
  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

I've got myself a good TRACE of a lot of previously and after error calls to libusb from the st-link code, and I'll gladly share the details since this is giving me the feeling about the index problem. It's just that I am not fully able to explain it in technical terms, it's just that, my tracing experiments...

[mosagepa]

What about this "home-made" trace I got?

BIEN (GOOD RESULT, ON FIRST EXECUTION): =====

DEBUG: I am going to call libusb_get_device_descriptor with IDs = 00001D6B:00000002...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 00001D6B:00000001...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 000005AC:00008206...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 000005AC:0000020C...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 000005AC:00001003...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 00001D6B:00000001...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 0000045E:000000CB...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 00001D6B:00000001...
DEBUG : libusb_get_string_descriptor_ascii() with sizeof(serial) = 64... done.
  desc.iSerialNumber = 0
  serial = 
done.
  desc.iSerialNumber = 1
  serial = STMicroelectronics
done.
  desc.iSerialNumber = 2
  **serial = STM32 STLink**
done.
  desc.iSerialNumber = 3
  **serial = 9?oMB48Q%C** 

MAL (BAD SUBSEQUENT RESULTS, SEE THE DIFFERING TAGS AND STRINGS ON APPARENTLY SAME CALLS): ====

DEBUG: I am going to call libusb_get_device_descriptor with IDs = 00001D6B:00000002...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 00001D6B:00000001...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 000005AC:00008206...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 000005AC:0000020C...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 000005AC:00001003...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 00001D6B:00000001...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 0000045E:000000CB...
DEBUG: I am going to call libusb_get_device_descriptor with IDs = 00001D6B:00000001...
DEBUG : libusb_get_string_descriptor_ascii() with sizeof(serial) = 64... done.
  desc.iSerialNumber = 0
  serial = 
done.
  desc.iSerialNumber = 1
  serial = STMicroelectronics
done.
  desc.iSerialNumber = 2
  **serial = STM32 Mass Storage**
done.
  desc.iSerialNumber = 3
  **serial = 000000000001**
done.```

[mosagepa]

Please btw tell me how can I insert CR+LFs within pasted code in order to edit my recent posts and make them more readable... ;)

[Nightwalker-87]

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.

[petertorelli]

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

[Nightwalker-87]

@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.

[GadgetAngel]

@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 2) NUCLEO-F103RB (STM32F103RB) using ST-LINK-V2-1 3) NUCLEO-F446RE (STM32F446RE) using ST-LINK/V2-1 4) NUCLEO-L433RC-P (STM32L433RC-P) using ST-LINK/V2-1 5) NUCLEO-F302R8 (STM32F302R8) using ST-LINK/V2-1 6) 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.

[Ant-ON]

@Nightwalker-87 I looked again at the changes when stlink V3 support was added. Here are the fixes for the bugs I found. Can you check work stlink v1 after it is applied to src/stlink-lib/usb.c?

--- a/src/stlink-lib/usb.c
+++ b/src/stlink-lib/usb.c
@@ -301,7 +301,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); }

@@ -431,6 +431,8 @@ int _stlink_usb_status(stlink_t * sl) {
         } else {
             sl->core_stat = TARGET_UNKNOWN;
         }
+    } else {
+        sl->core_stat = TARGET_UNKNOWN;
     }

     return(0);
@@ -469,19 +471,14 @@ int _stlink_usb_enter_swd_mode(stlink_t * sl) {
     unsigned char* const cmd  = sl->c_buf;
     ssize_t size;
     unsigned char* const data = sl->q_buf;
-    const uint32_t rep_len = sl->version.stlink_v > 1 ? 2 : 0;
+    const uint32_t rep_len = sl->version.jtag_api == STLINK_JTAG_API_V1 ? 0 : 2;
     int i = fill_command(sl, SG_DXFER_FROM_DEV, rep_len);

     cmd[i++] = STLINK_DEBUG_COMMAND;
     // select correct API-Version for entering SWD mode: V1 API (0x20) or V2 API (0x30).
     cmd[i++] = sl->version.jtag_api == STLINK_JTAG_API_V1 ? STLINK_DEBUG_APIV1_ENTER : STLINK_DEBUG_APIV2_ENTER;
     cmd[i++] = STLINK_DEBUG_ENTER_SWD;
-
-    if (rep_len == 0) {
-        size = send_only(slu, 1, cmd, slu->cmd_len);
-    } else {
-        size = send_recv(slu, 1, cmd, slu->cmd_len, data, rep_len);
-    }
+    size = send_recv(slu, 1, cmd, slu->cmd_len, data, rep_len);

     if (size == -1) {
         printf("[!] send_recv STLINK_DEBUG_ENTER\n");