STLINK/V3-SET: If the device fails to enter SWD mode, the usb device is not released

[TheFissk]

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

---

• Programmer/board type: STLINK/V3-SET
• Operating system an version: Linux (Ubuntu 22.04 LTS + a really out of date version of Debian)
• stlink tools version and/or git commit hash: v1.8.0
• stlink commandline tool name: Tested against st-flash and st-info

---

When there is no board connected to the programmer causing it to fail to enter SWD mode subsequent invokations of the tool hang before failing.

Commandline output:
These commands are separated by several seconds, I'm not machinegunning the tool expecting it to work. The first command returns immediately, the second hangs for ~10s

$ st-flash reset
st-flash 1.8.0
Failed to enter SWD mode
Failed to connect to target
Failed to parse flash type or unrecognized flash type //This line went to stderr rather than stdout
$ st-flash reset
st-flash 1.8.0
2024-05-24T10:41:08 ERROR usb.c: GET_VERSION send request failed: LIBUSB_ERROR_TIMEOUT
2024-05-24T10:41:11 ERROR usb.c: GET_CURRENT_MODE send request failed: LIBUSB_ERROR_TIMEOUT
2024-05-24T10:41:14 ERROR usb.c: GET_COM_FREQ send request failed: LIBUSB_ERROR_TIMEOUT
2024-05-24T10:41:17 ERROR usb.c: GET_CURRENT_MODE send request failed: LIBUSB_ERROR_TIMEOUT
2024-05-24T10:41:20 ERROR usb.c: ENTER_SWD send request failed: LIBUSB_ERROR_TIMEOUT
Failed to parse flash type or unrecognized flash type
Failed to enter SWD mode
Failed to connect to target
2024-05-24T10:41:23 ERROR usb.c: DEBUG_EXIT send request failed: LIBUSB_ERROR_TIMEOUT

I also tested it against st-info --chipid and it works in much the same way, but it suppresses the stderr output, so that the program hangs for a ~10 seconds before outputting:

$ st-info --chipid
Failed to enter SWD mode
0x0000

Plugging a board into the programmer once its entered this degraded state does not resolve the issue, it will continue to output the same errors

st-info --probe works as expected returning instantly regardless of whether or not the device was able to enter SWD mode in previous invokations of st-info --probe

The V2 programmer works as expected, returning instantly even after failing to enter SWD mode.

Expected/description:

If the V3 programmer should return instantly after failing to enter SWD mode, regardless of whether or not it was able to enter SWD mode previously.

[Nightwalker-87]

@Ant-ON: Can we be sure about that the STLINK-V3-SET is fully supported yet?
The only thing I found are the respective VID:PIDs in the udev-rules ...

[Ant-ON]

@Nightwalker-87 STLINK-V3-SET has the same commands as STLINK-V3, therefore the STLINK-V3-SET should be supported too

[Nightwalker-87]

So why shall there a problem then which does not seem to occur with other variants?
Users: Please test your devices and give feedback on any issues.

[ankurraji]

I have the same issue with my ST-LINK V3 SET.

sending flash reset command when no MCU is connected, leads to first this message

$ st-flash reset
st-flash 1.8.0
Failed to enter SWD mode
Failed to connect to target
Failed to parse flash type or unrecognized flash type

And when the command is triggered another time you will receive an error

$ st-flash reset
st-flash 1.8.0
2024-07-19T13:20:37 ERROR usb.c: GET_VERSION send request failed: LIBUSB_ERROR_TIMEOUT
2024-07-19T13:20:40 ERROR usb.c: GET_CURRENT_MODE send request failed: LIBUSB_ERROR_TIMEOUT
2024-07-19T13:20:43 ERROR usb.c: GET_COM_FREQ send request failed: LIBUSB_ERROR_TIMEOUT
2024-07-19T13:20:46 ERROR usb.c: GET_CURRENT_MODE send request failed: LIBUSB_ERROR_TIMEOUT
2024-07-19T13:20:49 ERROR usb.c: ENTER_SWD send request failed: LIBUSB_ERROR_TIMEOUT
Failed to enter SWD mode
Failed to connect to target
Failed to parse flash type or unrecognized flash type
2024-07-19T13:20:52 ERROR usb.c: DEBUG_EXIT send request failed: LIBUSB_ERROR_TIMEOUT

The debug flag does not give more information

$ st-flash reset --debug
st-flash 1.8.0
2024-07-19T13:20:59 ERROR usb.c: GET_VERSION send request failed: LIBUSB_ERROR_TIMEOUT
2024-07-19T13:21:02 ERROR usb.c: GET_CURRENT_MODE send request failed: LIBUSB_ERROR_TIMEOUT
2024-07-19T13:21:05 ERROR usb.c: GET_COM_FREQ send request failed: LIBUSB_ERROR_TIMEOUT
2024-07-19T13:21:08 ERROR usb.c: GET_CURRENT_MODE send request failed: LIBUSB_ERROR_TIMEOUT
2024-07-19T13:21:11 ERROR usb.c: ENTER_SWD send request failed: LIBUSB_ERROR_TIMEOUT
Failed to enter SWD mode
Failed to connect to target
Failed to parse flash type or unrecognized flash type
2024-07-19T13:21:14 ERROR usb.c: DEBUG_EXIT send request failed: LIBUSB_ERROR_TIMEOUT

Additionally, it looks like the ST-LINK V3 SET is stuck/hanging. This is something that I diagonalised with the LEDs and the response time delay when you execute the st-flash reset. Sometimes I have to wait for ~10 Secs to see any log message printed out in the terminal after the line st-flash 1.8.0 is printed.

The issue remains the same even though I connect the MCU back again to the ST-LINK V3 SET; only a power reset of debugger i.e. unplugging the USB cable and connecting it back again solves the issue.

Finally, as @TheFissk mentioned, I too have not observed any issue with ST-LINK V2 it just comes out of the command with an error, and is able to connect to the MCU when the MCU is connected again to the debugger. The V2 does not produce LIBUSB_ERROR_TIMEOUT error.

Flash reset with ST-LINK V2.

$ st-flash reset
st-flash 1.8.0
Failed to enter SWD mode
Failed to connect to target
Failed to parse flash type or unrecognized flash type

Feel free to comment, if more information is required 😃

[bfueldner]

I can confirm the behaviour like @ankurraji mentioned with v1.8.0 and ST-LINK V3 MINIE. So it seems not to depend only on the combination command set and ST-LINK V3 SET.

[Nightwalker-87]

Please investigate further. We need some volunteers with the appropriate hardware that are able to look into this.

[ypearson-bdai]

Got this on a stm32 G0 using a STlink-v3mini
st-flash 1.8.0
2024-10-24T13:09:06 ERROR usb.c: GET_VERSION send request failed: LIBUSB_ERROR_TIMEOUT
2024-10-24T13:09:09 ERROR usb.c: GET_CURRENT_MODE send request failed: LIBUSB_ERROR_TIMEOUT
2024-10-24T13:09:12 ERROR usb.c: GET_COM_FREQ send request failed: LIBUSB_ERROR_TIMEOUT
2024-10-24T13:09:15 ERROR usb.c: GET_CURRENT_MODE send request failed: LIBUSB_ERROR_TIMEOUT
2024-10-24T13:09:18 ERROR usb.c: ENTER_SWD send request failed: LIBUSB_ERROR_TIMEOUT
Failed to enter SWD mode
Failed to connect to target
Failed to parse flash type or unrecognized flash type
2024-10-24T13:09:21 ERROR usb.c: DEBUG_EXIT send request failed: LIBUSB_ERROR_TIMEOUT

[Nightwalker-87]

We are still looking for further investigation and further ideas here. Please contribute.

[jmmunoz86]

I'm having the same issue but using the ST-LINK from the nucleo-L476RG (FW version V2J45M31):

PS C:\Users\Jonathan\Desktop\nucleo_l476rg_freeRTOS_VSCODE> st-flash --reset  write .\build\nucleo_l476rg_freeRTOS.bin 0x08000000  
st-flash 1.8.0
libusb: info [cache_config_descriptors] could not access configuration descriptor 1 (dummy) for 'USB\VID_0BDA&PID_8153\001000001': [31] A device attached to the system is not functioning.
Failed to enter SWD mode
Failed to connect to target
Failed to parse flash type or unrecognized flash type

I could flash my device just once. Following flashes failed. I can connect my nucleo board with the STM32CubeProgrammer and flash it.
What always have appeared is that libusb line despite the success/failure of the flashing process.

[Nightwalker-87]

Please re-test this on a linux machine with a current libusb package from the default internal package source.

[TheFissk]

it still fails in the same way on my system, compiled against libusb 1.0.27

[Nightwalker-87]

As far as I could investigate, this needs to be addressed within /src/stlink-lib/usb.c.

[Nightwalker-87]

I suppose the bug is somewhere here in usb.c:

int32_t _stlink_usb_enter_swd_mode(stlink_t * sl) {
    struct stlink_libusb * const slu = sl->backend_data;
    unsigned char* const cmd  = sl->c_buf;
    ssize_t size;
    unsigned char* const data = sl->q_buf;
    const uint32_t rep_len = sl->version.jtag_api == STLINK_JTAG_API_V1 ? 0 : 2;
    int32_t 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;
    size = send_recv(slu, 1, cmd, slu->cmd_len, data, rep_len, CMD_CHECK_RETRY, "ENTER_SWD");

    return (size < 0 ? -1 : 0);
}

We find that STLINK_DEBUG_APIV3_ENTER is missing. The JTAG_API version is checked for v1 and if that turns out false, v2 is automatically selected. I could imagine this to be a relict from earlier times when STLINK/V3 programmers did not exist. That would also explain why this happens with different STLINK/V3 variants. (I expect that they all constantly fail to enter SWD mode.) As there are specific API V3 enums present, these would clearly require a STLINK_DEBUG_APIV3_ENTER.

[Nightwalker-87]

Along with this topic, I propose some restructuring in the codebase regarding existing STLINK commands, defined in commands.h. If technically possible, I'd consider it a good idea to separate and resort specific commands for /v1 /v2 and /v3. The idea would also include dissolving the entanglement between the three different APIs in common.c and move the resorted code to a separate source file in order to ease maintenance. This is also in the context of common.c historically being a relatively unstructured hodgepodge of everything. How do you think about this?

[Nightwalker-87]

To highlight this renaming has taken place:

• common.c --> common_legacy.c
• sg.c --> sg_legacy.c
• sg.h --> sg_legacy.h

I found that the whole STLINK/v3 implementation started here with commit 09ea99a.

[Nightwalker-87]

The STLINK-V3MINIE also failed to enter SWD mode here in a very similar way.
However, this was caused by a VCC wire connected to the wrong pin in a 20-pin JTAG header.
Note that the pin 2 VCC assignment is only optional here. There are other 20-pin pinouts where VCC is allocated to pin 2.

@TheFissk Can you rule out such a hardware-related cause?

[TheFissk]

@Nightwalker-87 I got the same behaviour on both of my V3 SETS, on both the 1.8 release, the latest changes in the develop branch. both with the provided mezzanine board attached and without. Always without any 3rd party boards attached (no chance that anything other than the official ST hardware was the source of the problem) So unless ST messed up the hardware on both of my programmers, its unlikely that hardware is to blame.

I should note that if I expect to be able to enter SWD (there is a board attached to my programmer) everything works as expected. Its only when there isn't a board attached, and I shouldn't be able to enter SWD that I see this problem. (ie on the second running of the command the program hangs with libusb timeout errors, rather than failing instantly as in the first running).

[Nightwalker-87]

@TheFissk: Thank you for the clarifications. We need to check further.

[rogermc2]

My device, Nucleo-F030R8, has been working well for quite some time. However, yesterday it started exhibiting the problems mentioned. I'm pretty sure after I had attempted a flash with no board connected. I'm sure I've done this a number of times in the past without problems. I think this problem started after a recent ST-LINK/V2-1 "upgrade" using STLinkUpgrade 3.16.7. st-info --probe.

Failed to enter SWD mode
Found 1 stlink programmers
version: V2J46S31
serial: 066DFF484971754867190739
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x000
dev-type: unknown

I have just managed to flash by dragging the executable onto the desktop "disc" image of my board. Somehow I managed to connect once but subsequent attempts failed.
Next I tried STM32CubeIDE which worked.
Then after closing STM32CubeIDE, all ST-Link functions are working again.
st-info --probe

Found 1 stlink programmers
version: V2J46S31
serial: 066DFF484971754867190739
flash: 65536 (pagesize: 1024)
sram: 8192
chipid: 0x440
dev-type: STM32F05x

[raul-klg]

Hi all!

I've just reread all of the comments on this issue, but I'm not clear what are the options or next steps. I would appreciate if someone could point how to help and if is there any workaround.

In our case, we are using ST-LINK V3PWR and when target is not available, the ST-LINK will hang indefinitely until we reconnect the USB cable. We already took care to upgrade the ST-LINK firmware (it is now shown as version V4J6). For us this is a major problem since we run ST-LINK remotely and, at the moment, USB cable reconnect requires operator physical intervention.

Best Regards,

[raul-klg]

We find that STLINK_DEBUG_APIV3_ENTER is missing. The JTAG_API version is checked for v1 and if that turns out false, v2 is automatically selected. I could imagine this to be a relict from earlier times when STLINK/V3 programmers did not exist. That would also explain why this happens with different STLINK/V3 variants. (I expect that they all constantly fail to enter SWD mode.) As there are specific API V3 enums present, these would clearly require a STLINK_DEBUG_APIV3_ENTER.

Checking at the latest commit code, I see that only a few commands are specific to V3. Therefore I guess that either some V3 capabilities are pending to be implemented or almost all V3 capabilities can be used via V2 commands.

Also I have noticed that when using stm32cubeprogrammer (on linux) the problem still stands so I lean towards pointing to some instability in the ST-LINK firmware.

[Ant-ON]

@raul-klg It is normal that only several commands have the APIV3 suffix. This suffix informs about commands added in version 3 of the protocol. The initialization command (STLINK_DEBUG_APIV3_ENTER) has not changed.

[raul-klg]

Thanks for the reply, Ant-ON

Meanwhile I though some information on our side could be helpful, so I'm attaching a st-info --serial log with verbose libusb level. In it you can see how there are several libusb timeouts so I'd say that ST-LINK usb communication are stalled somehow.

I got the log with the command LIBUSB_DEBUG=4 st-info --serial 2>&1 | tee stlink-error

Edit: I cannot attach the log, the interesting part is this:

[ 0.008285] [00012173] libusb: debug [libusb_open] open 1.49
[ 0.008297] [00012173] libusb: debug [usbi_add_event_source] add fd 7 events 4
[ 0.008299] [00012173] libusb: debug [libusb_kernel_driver_active] interface 0
[ 0.008301] [00012173] libusb: debug [libusb_get_configuration]  
[ 0.008315] [00012173] libusb: debug [libusb_get_configuration] active config 1
[ 0.008317] [00012173] libusb: debug [libusb_claim_interface] interface 0
[ 0.008326] [00012173] libusb: debug [libusb_submit_transfer] transfer 0x5634670e9810
[ 0.008328] [00012173] libusb: debug [add_to_flying_list] arm timer for timeout in 3000ms (first in line)
[ 0.008330] [00012173] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 16
[ 0.008342] [00012173] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.008344] [00012173] libusb: debug [handle_events] event sources modified, reallocating event data
[ 0.008346] [00012173] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 0.008354] [00012173] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 0.008356] [00012173] libusb: debug [reap_for_handle] urb type=3 status=0 transferred=16
[ 0.008357] [00012173] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1
[ 0.008358] [00012173] libusb: debug [handle_bulk_completion] all URBs in transfer reaped --> complete!
[ 0.008359] [00012173] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 0.008361] [00012173] libusb: debug [usbi_handle_transfer_completion] transfer 0x5634670e9810 has callback 0x7fb2e9bac9d0
[ 0.008363] [00012173] libusb: debug [sync_transfer_cb] actual_length=16
[ 0.008364] [00012173] libusb: debug [libusb_free_transfer] transfer 0x5634670e9810
[ 0.008366] [00012173] libusb: debug [libusb_submit_transfer] transfer 0x5634670e8100
[ 0.008367] [00012173] libusb: debug [add_to_flying_list] arm timer for timeout in 3000ms (first in line)
[ 0.008369] [00012173] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 12
[ 0.008378] [00012173] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.008379] [00012173] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 3.008606] [00012173] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 3.008642] [00012173] libusb: debug [libusb_cancel_transfer] transfer 0x5634670e8100
[ 3.008800] [00012173] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 3.008828] [00012173] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 3.008836] [00012173] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 3.008852] [00012173] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 3.008886] [00012173] libusb: debug [reap_for_handle] urb type=3 status=-2 transferred=0
[ 3.008894] [00012173] libusb: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
[ 3.008901] [00012173] libusb: debug [handle_bulk_completion] abnormal reap: urb status -2
[ 3.008907] [00012173] libusb: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
[ 3.008914] [00012173] libusb: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
[ 3.008919] [00012173] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 3.008928] [00012173] libusb: debug [usbi_handle_transfer_completion] transfer 0x5634670e8100 has callback 0x7fb2e9bac9d0
[ 3.008935] [00012173] libusb: debug [sync_transfer_cb] actual_length=0
[ 3.008946] [00012173] libusb: debug [libusb_free_transfer] transfer 0x5634670e8100
[ 3.008961] [00012173] libusb: debug [libusb_submit_transfer] transfer 0x5634670f3f20
[ 3.008967] [00012173] libusb: debug [add_to_flying_list] arm timer for timeout in 3000ms (first in line)
[ 3.008979] [00012173] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 16
[ 3.009015] [00012173] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 3.009026] [00012173] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 6.009154] [00012173] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 6.009187] [00012173] libusb: debug [libusb_cancel_transfer] transfer 0x5634670f3f20
[ 6.009356] [00012173] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 6.009386] [00012173] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 6.009394] [00012173] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 6.009410] [00012173] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 6.009425] [00012173] libusb: debug [reap_for_handle] urb type=3 status=-2 transferred=0
[ 6.009432] [00012173] libusb: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
[ 6.009439] [00012173] libusb: debug [handle_bulk_completion] abnormal reap: urb status -2
[ 6.009445] [00012173] libusb: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting

[rogermc2]

I fix it by erasing full chip with STM32 Programmer then reinstalling with STM32 Programmer. Also, when other things respond with zeroes in some fields, STM32 Programmer has no problem, all fields appear correctly.
Also, st-link --probe only prints the first item of the descriptor list of chip families (when relevant) whereas STM32 Programmer reports the full descriptor list with family symbols separated by "/".

[raul-klg]

I fix it by erasing full chip with STM32 Programmer then reinstalling with STM32 Programmer. Also, when other things respond with zeroes in some fields, STM32 Programmer has no problem, all fields appear correctly. Also, st-link --probe only prints the first item of the descriptor list of chip families (when relevant) whereas STM32 Programmer reports the full descriptor list with family symbols separated by "/".

Thank you for this reply. From your words I understand that you do a full chip erase from STM32CubeProgrammer against ST-LINK V3/PWR via some other debugging device (maybe one other ST-LINK). I can do this, but how would you reprogram the /faulty/ ST-LINK, would the STLinkUpgradeTool work in this case?

Regards,

[rogermc2]

My st-links are V2 on stm32 boards. I do a full chip erase with st32 programmer then I use st32 programmer's st-link "upgrade" facility to reprogram the chip's st-link. I'm no expert in this field so I'm not really sure what's going on, just that it solves my st-link chip unrecognized problem whenever it occurs