On Wed, Jun 23, 2021 at 10:06 PM Xiaofan Chen <xiaof...@gmail.com> wrote:
>
> On Wed, Jun 23, 2021 at 8:13 PM Xiaofan Chen <xiaof...@gmail.com> wrote:
> >
> > On Sat, Jun 19, 2021 at 5:11 PM Xiaofan Chen <xiaof...@gmail.com> wrote:
> > >
> > > On Sun, Jun 13, 2021 at 7:02 PM Xiaofan Chen <xiaof...@gmail.com> wrote:
> > >
> > > > > I can see that there is an issue with ST-Link now. I can
> > > > > reproduce it myself.
> > > > > https://sourceforge.net/p/openocd/tickets/308/
> > > > > https://github.com/libusb/libusb/issues/928
> > > >
> > > > Based on my investigation, the issue is not with libusb
> > > > but rather openocd. Please take a look at the libusb
> > > > ticket #928 to see if my analysis is correct or not. Thanks.
> > > >
> > >
> > > Just wondering if anyone has looked into Ticket 308. Thanks.
> > > https://sourceforge.net/p/openocd/tickets/308/
> > >
> > > I do not have issues connecting to stlink with the latest
> > > libusb git from the following project which also uses libusb.
> > > https://github.com/stlink-org/stlink
> >
> > I have made some progress to identify the particular libusb
> > commit which causes the differences in behavior.
> >
> > Please refer to my updates here.
> > https://sourceforge.net/p/openocd/tickets/308/
> > https://github.com/libusb/libusb/issues/928
> >
> > Particular complicated libusb commit (by right it should be splitted
> > into multiple changes, but anyway we are short of maintainers):
> > https://github.com/libusb/libusb/commit/32a22069428cda9d63aa666e92fb8882a83d4515
> >
> > However, I am not so sure if that paticular change is the root cause
> > or openocd stlink_usb.c is the culprit.
>
> Thanks to the pointer of the original reporter (asier70) and
> Antonio Borneo in openocd ticket 308, I think
> I have identify the issue in stlink_usb.c.
>
> Yes the above libusb patch libusb (32a2206) changed a bit of the behavior
> of libusb code but openocd stlink_usb.c does not handle the context right.
> It assumes that libusb_init() is called with NULL context but that is not
> true as per libusb_helper.c.
>
> Why FTDI adapter does not have such issue, because it does not use
> libusb_helper.h and uses 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 do not use the context.
>
> Please help to check if my analysis is correct or not. Thanks. I am
> not a programmer myself.
To proof my analysis, I use the following dirty fix of libusb_helper.c,
then openocd git latest HEAD has no issues with latest libsub git HEAD.
I am not saying this is the right fix though.
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);
openocd on master [!] took 1m36s ❯ brew info libusb
libusb: stable 1.0.24 (bottled), HEAD
Library for USB device access
https://libusb.info/
/opt/homebrew/Cellar/libusb/HEAD-e3dda19 (22 files, 565.0KB) *
Built from source on 2021-06-23 at 22:08:47
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 on master [!] ❯ ./src/openocd -s ./tcl -f board/stm32f4discovery.cfg
Open On-Chip Debugger 0.11.0+dev-00225-g42a0bf3c3-dirty (2021-06-23-22:13)
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
--
Xiaofan
