STM32F100RBT6: Failed to read core_id and unknown device #1045
Comments
WK-Kz
changed the title
|
Thx for reporting. I can verify this with my STM32VL Discovery board that comes with this chip. |
Nightwalker-87
changed the title
Nightwalker-87
changed the title
|
Have the same problem. Latest working commit: e3aa887 |
|
How I wrote in stlinkV3 issue: it patch may break v1 support ( #820 (comment) ) @wk-M Can you try patch to develop branch: |
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. |
|
@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. |
|
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. |
|
F32 use libusbx-1.0.23. |
|
Sorry for the late response. From the command: |
|
Is this being tackled, any advance? |
|
I update. |
|
Libusb-0.1.x is not used and thus not needed by this toolset. I have a STM32F100RBT6 (VL Discovery) with STLINK-V1 as well, but unfortunately had no time to run any tests yet besides professional work... |
|
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. |
|
New update: |
|
What about this "home-made" trace I got? BIEN (GOOD RESULT, ON FIRST EXECUTION): MAL (BAD SUBSEQUENT RESULTS, SEE THE DIFFERING TAGS AND STRINGS ON APPARENTLY SAME CALLS): |
|
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... ;) |
|
Usually one can simply copy console output as is and paste it and use < > afterwards to define a codeblock formatting around it. |
|
@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. |
I have both Mint Linux (20.1) machine and Windows 10 machine to do testing on the following boards:
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. |
|
@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 --- 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"); |
|
On Wed, Mar 10, 2021 at 08:26:19AM -0800, mosagepa wrote:
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"
This really looks as if it was able to enumerate that the STLINK
device existes and then.... fails to communicate with the STLINK
completely.
This looks as if you might have a permission problem on the USB
device. Try running the command as root, and if you get further,
please install the correct udev rules to be able to use the device as
a normal user.
…-- REW
|
|
@rewolff My udev settings are ok and as I said above in another post a compilation of libusb calls mixed code which asks also for the serial works beautifully and consistenly with the ST Link v1 in the VL Discovery, so I am pretty sure privileges is not the problem. Also, @Nightwalker-87 had the same log messages and he surely doesn't have a privilege issue neither. As I pointed out before, the problem seems to be in something that goes wrong just after an initial inquiry by So the first "pass" takes the VL Discovery into some wrong "state" so to speak which also causes both red leds to light. From then on any access gets directed to the "storage device" which we know it's broken by design and we don't use for anything in Linux case, it addresses that "part" of the device when it should address the "ST Link" part of it, so to speak. |
|
@mosagepa See the third part of my patch #1045 (comment). I think that the process of receiving information stops with the error because the application does not read the response from the STLINK_DEBUG_ENTER_SWD command. |
|
@Ant-ON Please, I highly recommend that when you have a spare time you check this out. I think that proper comparison of the libusb calls that an Also, I don't fully understand the inner working of the inside code you mention. All I know is, if st-link were to (effectively after all its encapsulations, switches and checks) reduce its sequence of (final, ultimate) libusb calls to the same I've been using in my particular code (which is something quite natural to expect), then it should work flawlessly also. So why does it not? |
|
@Ant-ON: I can test your code with my STLink/V1 now, after merging I know by now that the merge itself does not make any difference to the behaviour of my device, but we can now be sure that there will be no more code ingress from old parts because we'll only accept new PRs that start from this commit or later. Hence I ask everybody to work with latest |
|
@Ant-ON: Yes, that seems to be the key: Great work! Thx. 🎉 I find both red LEDs to remain in a lit up state, but assume that this is an equal behaviour to the red LED turning blue on my STLink/V2-clone programmer when testing with my bluepill-board for other open issues. I'll now continue to test other commands with it. |
|
General test with st-flash: Flashing: However I find that no LED is blinking... 😞 |
|
I've built the latest on Ubuntu 18.04 running in latest VM_Virtualbox (git clone, make clean, make release, make install). I had to do sudo ldconfig in addition as I got error with missing lib.. something. |
|
@igor-m Try apply patch to develop branch from #1045 (comment) |
|
With applied patch (the patch lines at 431 are not valid anymore, it seems): ..and the LED fades 👍 |
|
@Nightwalker-87: the leds on the VL board are called LED_BLUE and LED_GREEN - double-check in your arduino Blink source.. |
|
On my STM32VL Discovery Board the status LEDs in the front part are called LD1 and LD2 and both are red ones. |
|
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
added
bug/fixed
status/resolved
and removed
bug/needs-fix
needs/testing
labels
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.
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:
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:
For st-info:
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 runningst-util. However, the board is able to be detected when running lsusb.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
The text was updated successfully, but these errors were encountered: