pyOCD: v0.33.0 USB Error: Operation timed out

Hello, I investigated a little bit more because I was surprised by your answer [the API at FW level never changed], but you are also right: it can work, especially on the V3, because endpoint size is 512 bytes wide; so the USB IN data is retrieved by the host USB driver in a single request, and the ST-Link is happy ! [I was wrong in my first analysis] Then, the behavior during next command depends on the host implementation: if IN data are flushed before sending a new command, host and device will be aligned again for this new command. On V2 it could be different (I have not tried) as long as endpoint size is 64 bytes, so the host driver must issue 2 IN requests to make the FW ‘happy’, and I’m not sure it does it if the application asks only for 36 bytes. I don’t know if libusb provides the ability to flush endpoints (I did not find in a quick search), but at least winusb does with WinUsb_FlushPipe(), … and we use it in our STLinkUSBDriver.dll (this increases a little bit the USB comm robustness)

cc @schstm

From my initial investigation, it looks like this is actually a bug in the STLinkV2 firmware. (To my great surprise! As well as relief that it’s apparently not something strange with how libusb is built.)

The reason it is connected with pyocd 0.33 is that this version of pyocd adds support for the JTAG_GET_BOARD_IDENTIFIERS command added to STLink V2J36 and V3J6. It’s this specific command that causes the timeout error. If the sending of this command is disabled, pyocd connects and communicates with the STLInk just fine.

The attached test_stlink_board_id_timeout.py script is a stripped down version of the code to send the STLink command sequence that reproduces the timeout. It sends the commands to the first available STLink it sees.

Next steps:

• Pyocd v0.33.1 will be released shortly that removes the use of the JTAG_GET_BOARD_IDENTIFIERS command.
• Do some more testing to determine in exactly which version the bug is introduced.
• Get a USB trace.
• Report this issue to STMicro.

test_stlink_board_id_timeout.zip

Finally I can reproduce it, on both Windows and Linux. It took upgrading the firmware to V2J39M27 (from V2J37M27 on this particular Nucleo-G031).

STLinkV3 does not seem to be affected. At least, I’ve not heard of any reports, nor can I reproduce it after upgrading a Nucleo-H743 to the latest V3 firmware V3J9M3. (Of course, that’s not completely certain.)

@flit Finally i’ve updated my programmer using STM32CubeProgrammer to version V2J39S7.

Launch of pyocd list -vv -L “*trace=debug”:

0000546 D setting log level debug for ['pyocd.trace', 'pyocd.coresight.ap.trace', 'pyocd.utility.notification.trace', 'pyocd.coresight.dap.trace', 'pyocd.flash.flash.trace', 'pyocd.debug.semihost.trace', 'pyocd.gdbserver.packet_io.trace', 'pyocd.probe.pydapaccess.interface.hidapi_backend.trace', 'pyocd.probe.pydapaccess.interface.pyusb_backend.trace', 'pyocd.probe.pydapaccess.interface.pyusb_v2_backend.trace', 'pyocd.probe.pydapaccess.interface.pywinusb_backend.trace', 'pyocd.probe.pydapaccess.dap_access_cmsis_dap.trace', 'pyocd.probe.cmsis_dap_probe.trace', 'pyocd.probe.jlink_probe.trace', 'pyocd.probe.tcp_client_probe.trace', 'pyocd.probe.stlink.usb.trace', 'pyocd_pemicro.pemicro_probe.trace', 'pyocd.gdbserver.gdbserver.trace', 'pyocd.probe.tcp_probe_server.trace'] [__main__]
0000546 D Project directory: C:\Users\blokh\Desktop\APSTEC_GIT\HardwareQA\magtool [session]
0000657 D   USB CMD> (16) f5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [usb]
0000658 D   USB IN < (req 2 bytes) [usb]
0000658 D   USB IN < (2) 00 01 [usb]
0000659 D   USB CMD> (16) f3 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [usb]
0000659 D   USB CMD> (16) f1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [usb]
0000662 D   USB IN < (req 6 bytes) [usb]
0000713 D   USB IN < (6) 29 c7 83 04 48 37 [usb]
0000713 D STLink probe 540018000700004B474D4D4E firmware version: V2J39M7 [stlink]
0000713 D   USB CMD> (16) f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [usb]
0000714 D   USB IN < (req 8 bytes) [usb]
0000714 D   USB IN < (8) ed 05 00 00 fb 07 00 00 [usb]
0000715 D   USB CMD> (16) f2 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [usb]
0000715 D   USB IN < (req 36 bytes) [usb]
0000716 D   USB IN < (36) 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [usb]
0000716 D   USB CMD> (16) f5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [usb]
0001721 C USB Error: [Errno 10060] Operation timed out [__main__]

Backup to ST-Link version V2.J34.S7 solves problem with pyocd v0.33.0

When using ST-Link version V2J39S7. Backup to pyocd v.0.32.3 and libusb 1.0.25 dll file in Python folder solves problem.

@cederom Indeed! The interesting thing, though, is that @BlokhinDima reported it failing on Windows, too. Presumably he had the latest libusb installed, pre-built by the libusb team—but this needs to be verified. I’m not doing anything special building the libusb in libusb-package for either Windows or Linux, just following the readmes from the libusb repo.

Trying the solution of @BlokhinDima under Windows 10 seems te be working fine for me as well (downgraded using pip install pyocd==0.32.3). Not placing the libusb-1.0.dll file in the python root folder results in a No available debug probes are connected error. But when the libusb dll file is placed in the root folder pyocd list works as intended.

Some most common issues:

• try running as administrator/root.
• make sure you have read/write access to the usb device.
• if you run over USB HUB try connecting directly.
• change USB port.
• changhe USB cable.
• make sure nothing else it using the device (i.e. modem driver, serial port, other application, etc).

If problem persist you may:

• remove built-in libusb and see if problem exist with system provided libusb.
• step by step use older libusb and see if problem persist.

If problem persist you may:

1. uninstall pip provided pyocd package.
2. git clone pyocd upstream.
3. try running release, previous release–, devel branch.
4. see how you can find a solution for a problem or when+why things start working.

@vacagonzalo That’s great! I’ll definitely add this to the documentation and udev readme.

Assuming that @BlokhinDima’s case is fixed with an STLink firmware upgrade, it’s still curious that pyocd 0.32.3 works without the firmware upgrade.

@vacagonzalo Interesting, you get the same error as on @BlokhinDima does on Windows. Thanks for providing the debug trace and system details.

I’ve retested on Ubuntu 18.04.6 and 20.04.3 (same kernel, etc as you), and Windows 10 1909 (all x86_64). On Windows, I tested with git-bash, cmd.exe, and PS. Of course, everything works fine. 😔

One notable difference with my test systems is that they are all VMs running in VMWare Fusion Pro 12.2.1 on a 2018 MacBook Pro (x86_64) under macOS 11.6.2. I don’t have a “real” Windows or Linux machine.

My current plan is to release v0.33.1 soon that will revert the inclusion of libusb-package (and thus requires users to manually install libusb on non-Linux systems), then continue to try to reproduce and debug. The main focus will be on Windows, since that’s the system where installing libusb is the most confusing for users. (For Linux, the use of the libusb-package version of libusb was primarily to ensure consistency.)

I may be able to put together a test script, and will report back to this issue to request help running it on affected systems.