OpenOCD - Open On-Chip Debugger / Tickets / #308 ST-link connect issue using latest libusb-1.0.dll

Xiaofan Chen - 2021-06-11

I can reproduce the issue under macOS.
https://github.com/libusb/libusb/issues/928

--
Xiaofan

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Xiaofan Chen - 2021-06-15

Based on my testing in the libusb issue #928, this seems to be an openocd issue and not libusb issue.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- asier70 - 2021-06-15
  
  For unknown reason libusb-1.0.dll compiled on March works, but the latest compilation has a problem with st-link..
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Xiaofan Chen - 2021-06-15
    
    Yes this is correct. So some changes in libusb triggered the problem. But my testing shows that the problem may well be related to openocd st-link codes, as other debug adapters have no issues. Github stlink.org stlink project also has no issues.
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Xiaofan Chen - 2021-06-15

https://github.com/libusb/libusb/issues/928
Based on my testing, most likely the issue is with openocd ST-Link
codes. It can not find the ST-Link, strange.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

After a little investigation I've found place where issue should be searched.
File "stlink_usb.c":

static int stlink_usb_version(void *handle)
{
    int res;
    uint32_t flags;
    uint16_t version;
    uint8_t v, x, y, jtag, swim, msd, bridge = 0;
    char v_str[5 * (1 + 3) + 1]; /* VvJjMmBbSs */
    char *p;
    struct stlink_usb_handle_s *h = handle;

    assert(handle != NULL);

    stlink_usb_init_buffer(handle, h->rx_ep, 6);

    h->cmdbuf[h->cmdidx++] = STLINK_GET_VERSION;

    res = stlink_usb_xfer_noerrcheck(handle, h->databuf, 6);

    if (res != ERROR_OK)
        return res;
  // ....

Function "stlink_usb_xfer_noerrcheck()" doesn't exit.
Some fault in it closes openocd.

👍

Xiaofan Chen - 2021-06-22

Not so sure if this one triggers the problem.
http://openocd.zylin.com/gitweb?p=openocd.git;a=commitdiff;h=68e200c660aefe960e351452748f299c4a334474

And I am not so sure which libusb commit triggers this in the first place.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Xiaofan Chen - 2021-06-22

No, it is not that due to that commit. I revert that commit and the issue is still there under my Mac Mini M1.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Antonio Borneo - 2021-06-22

Is it possible for you to use git bisect?
Not only on OpenOCD using the latest libusb, but also on libusb using latest OpenOCD.
This will highlight when in OpenOCD and in libusb you get the issue.

Another thing you could try is to NOT define USE_LIBUSB_ASYNCIO. It is defined by default with libusb1. Just comment out the lines below in src/jtag/drivers/stlink_usb.c
62 #ifdef HAVE_LIBUSB1
63 #define USE_LIBUSB_ASYNCIO
64 #endif

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- asier70 - 2021-06-23
  
  I am not familiar with this advanced tool.
  
  After commenting ASYNCIO define, st-link started to work without any problem. That was good idea.
  
  I continued previous investigation. I've found more accurate function which is a source of this issue. In stlink_usb.c file there is a function:
  
  static void sync_transfer_wait_for_completion(struct libusb_transfer *transfer) { int r, *completed = transfer->user_data; /* Assuming a single libusb context exists. There no existing interface into this * module to pass a libusb context. */ struct libusb_context *ctx = NULL; while (!*completed) { r = libusb_handle_events_completed(ctx, completed); if (r < 0) { if (r == LIBUSB_ERROR_INTERRUPTED) continue; libusb_cancel_transfer(transfer); continue; } } }
  
  Function libusb_handle_events_completed() (located in libusb library file io.c) used above at first calling doesn't return and after about 2 seconds opendocd is exited without any warning.
  
  Xiaofan Chen mentioned about this commit:
  https://github.com/libusb/libusb/commit/32a22069428cda9d63aa666e92fb8882a83d4515
  Bingo!
  This commit causes issue with st-link.
  Earlier commit works fine :)
  
  👍
  1
  
  Last edit: asier70 2021-06-23
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Xiaofan Chen - 2021-06-23
    
    I guess this assumption is not somehow not correct.
    
    /* Assuming a single libusb context exists. There no existing interface into this * module to pass a libusb context. */ struct libusb_context *ctx = NULL;
    
    It seems to me the problem is that libusb_init() is not called with NULL context.
    https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/libusb_helper.c
    if (libusb_init(&jtag_libusb_context) < 0)
    return ERROR_FAIL;
    
    Last edit: Xiaofan Chen 2021-06-23
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Xiaofan Chen - 2021-06-23
      
      You can see ftdi mpsse backend has no such issue.
      https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/mpsse.c
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Xiaofan Chen - 2021-06-23
        
        In summary, looks like the big patch in libusb (32a2206) changed a bit of the behavior of libusb code but the root cause of this anomaly is that openocd stlink_usb.c does not handle the context right.
        
        Why FTDI adapter does not have such issue, because it does not use libusb_helper.h and uses properly libusb by itself with the mpsse backend.
        https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/mpsse.c
        
        Why does other libusb_helper based adapter not have such an issue, because they do not use async transfer and not use the context.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Xiaofan Chen - 2021-06-23
        
        To proof my theory, I apply the following dirty fix to openocd and now latest openocd git has not issues with latest libusb git.
        
        https://github.com/libusb/libusb/issues/928
        ~~~
        diff --git a/src/jtag/drivers/libusb_helper.c b/src/jtag/drivers/libusb_helper.c
        index f0122d534..05c6e5574 100644
        --- a/src/jtag/drivers/libusb_helper.c
        +++ b/src/jtag/drivers/libusb_helper.c
        @@ -163,7 +163,7 @@ int jtag_libusb_open(const uint16_t vids[], const uint16_t pids[],
        bool serial_mismatch = false;
        struct libusb_device_handle *libusb_handle = NULL;
        
        if (libusb_init(&jtag_libusb_context) < 0)
        
        if (libusb_init(NULL) < 0)
        return ERROR_FAIL;
        cnt = libusb_get_device_list(jtag_libusb_context, &devs);
        
        ~~~
        
        👍
        1
        
        Last edit: Xiaofan Chen 2021-06-23
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Antonio Borneo - 2021-06-23
        
        On Wed, Jun 23, 2021 at 4:20 PM Xiaofan Chen
        xiaofanc@users.sourceforge.net wrote:
        
        To proof my theory, I apply the following dirty fix to openocd and now latest openocd git has not issues with latest libusb git.
        
        https://github.com/libusb/libusb/issues/928
        diff --git a/src/jtag/drivers/libusb_helper.c b/src/jtag/drivers/libusb_helper.c
        index f0122d534..05c6e5574 100644
        --- a/src/jtag/drivers/libusb_helper.c
        +++ b/src/jtag/drivers/libusb_helper.c
        @@ -163,7 +163,7 @@ int jtag_libusb_open(const uint16_t vids[], const uint16_t pids[],
        bool serial_mismatch = false;
        struct libusb_device_handle *libusb_handle = NULL;
        
        if (libusb_init(&jtag_libusb_context) < 0)
        
        if (libusb_init(NULL) < 0)
        return ERROR_FAIL;
        cnt = libusb_get_device_list(jtag_libusb_context, &devs);
        
        Now it's clear!
        The bug is inside stlink driver in OpenOCD
        Thanks for the dirty fix, it helps identifying the issue.
        Strange that it doesn't crash in Linux too!
        
        I will put a patch in openocd gerrit and report to you the link.
        It would be great if you could test it and approve it in gerrit.
        
        Antonio
        
        👍
        2
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
        
        Xiaofan Chen - 2021-06-24
        
        Reviewed in gerrit and the fix is good. Thanks.
        http://openocd.zylin.com/#/c/6331/1
        
        Last edit: Xiaofan Chen 2021-06-24
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Xiaofan Chen - 2021-06-23

@asier70
From the libusb side, I think you have narrowed down pretty close, you can check before and after this particular big commit.
https://github.com/libusb/libusb/commit/32a22069428cda9d63aa666e92fb8882a83d4515

Last edit: Xiaofan Chen 2021-06-23

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Xiaofan Chen - 2021-06-23
  
  Okay, with my Mac Mini M1 I can confirm the above commit is causing the differences in openocd. But I am not so sure if libusb change is the real issue or not.
  
  openocd/test/stm32 ❯ brew info libusb
  libusb: stable 1.0.24 (bottled), HEAD
  Library for USB device access
  https://libusb.info/
  /opt/homebrew/Cellar/libusb/HEAD-a2b81ae (6 files, 769.3KB) *
  Built from source
  From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/libusb.rb
  License: LGPL-2.1-or-later
  ==> Options
  --HEAD
  Install HEAD version
  ==> Analytics
  install: 60,921 (30 days), 194,606 (90 days), 818,103 (365 days)
  install-on-request: 6,327 (30 days), 18,921 (90 days), 78,245 (365 days)
  build-error: 0 (30 days)
  
  openocd/test/stm32 ❯ openocd -s /opt/homebrew/share/openocd/scripts -f board/stm32f4discovery.cfg
  Open On-Chip Debugger 0.11.0
  Licensed under GNU GPL v2
  For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
  Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
  srst_only separate srst_nogate srst_open_drain connect_deassert_srst
  
  Info : Listening on port 6666 for tcl connections
  Info : Listening on port 4444 for telnet connections
  Info : clock speed 2000 kHz
  Info : STLINK V2J30S0 (API v2) VID:PID 0483:3748
  Info : Target voltage: 2.876336
  Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
  Info : starting gdb server for stm32f4x.cpu on 3333
  Info : Listening on port 3333 for gdb connections
  
  openocd/test/stm32 ❯ brew info libusb
  libusb: stable 1.0.24 (bottled), HEAD
  Library for USB device access
  https://libusb.info/
  /opt/homebrew/Cellar/libusb/HEAD-32a2206 (6 files, 767.5KB) *
  Built from source
  From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/libusb.rb
  License: LGPL-2.1-or-later
  ==> Options
  --HEAD
  Install HEAD version
  ==> Analytics
  install: 60,921 (30 days), 194,606 (90 days), 818,103 (365 days)
  install-on-request: 6,327 (30 days), 18,921 (90 days), 78,245 (365 days)
  build-error: 0 (30 days)
  
  openocd/test/stm32 ❯ openocd -s /opt/homebrew/share/openocd/scripts -f board/stm32f4discovery.cfg
  Open On-Chip Debugger 0.11.0
  Licensed under GNU GPL v2
  For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
  Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
  srst_only separate srst_nogate srst_open_drain connect_deassert_srst
  
  Info : Listening on port 6666 for tcl connections
  Info : Listening on port 4444 for telnet connections
  Info : clock speed 2000 kHz
  [1] 19689 segmentation fault openocd -s /opt/homebrew/share/openocd/scripts -f board/stm32f4discovery.cfg
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Matthijs Kooijman - 2022-04-20

I believe this is fixed in openocd git: https://review.openocd.org/gitweb?p=openocd.git;a=commitdiff;h=cff0e417da58adef1ceef9a63a99412c2cc87ff3

Should this issue be closed?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Antonio Borneo - 2022-04-20

status: new --> closed

Resolution: --> review.openocd.org/6331

Type: --> bug
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Antonio Borneo - 2022-04-20

yes, I'm closing it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ST-link connect issue using latest libusb-1.0.dll

The Open On-Chip Debugger

Milestone

Searches

Help

#308 ST-link connect issue using latest libusb-1.0.dll

Discussion