Menu
▾
▴
#462 Problems on arm64 host
I'm attempting to use openocd to connect to a STLink V3Mods using a Raspberry Pi 5 (arm64) host.
I've built OpenOCD on the host using the cloned master repo from https://github.com/openocd-org/openocd.
As im guessing this could be libusb related, ive tried the os repo version of libusb, and also built libusb from the github master.
The errors i see are (libusb also has debug output enabled):
Debug: 111 4 target.c:1598 handle_target_init_command(): Initializing targets...
Debug: 112 4 mem_ap.c:61 mem_ap_init_target(): [stm32h7x.ap2] mem_ap_init_target
Debug: 113 4 semihosting_common.c:109 semihosting_common_init():
Debug: 114 4 stlink_usb.c:5120 stlink_dap_init(): stlink_dap_init()
Debug: 115 4 stlink_usb.c:3732 stlink_open(): stlink_open
Debug: 116 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3744 serial:
Debug: 117 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3748 serial:
Debug: 118 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374b serial:
Debug: 119 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374d serial:
Debug: 120 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374e serial:
Debug: 121 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374f serial:
Debug: 122 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3752 serial:
Debug: 123 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3753 serial:
Debug: 124 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3754 serial:
Debug: 125 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3755 serial:
Debug: 126 4 stlink_usb.c:3744 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3757 serial:
libusb: warning [libusb_init] installing new context as implicit default
libusb: error [submit_bulk_transfer] submiturb failed, errno=2
Debug: 127 10 stlink_usb.c:686 jtag_libusb_bulk_transfer_n(): ERROR, failed to submit transfer 0, error -1
libusb: warning [libusb_init] installing new context as implicit default
libusb: error [submit_bulk_transfer] submiturb failed, errno=2
Debug: 128 3482 stlink_usb.c:686 jtag_libusb_bulk_transfer_n(): ERROR, failed to submit transfer 0, error -1
Error: 129 3482 stlink_usb.c:3470 stlink_usb_usb_open(): read version failed
libusb: error [submit_bulk_transfer] submiturb failed, errno=2
Debug: 130 3482 stlink_usb.c:686 jtag_libusb_bulk_transfer_n(): ERROR, failed to submit transfer 0, error -1
Debug: 131 3482 command.c:453 jim_exec_command(): Command 'init' failed with error code -4
User : 132 3482 command.c:531 command_run_line(): openocd_erase.cfg:12: Error:
in procedure 'script'
at file "embedded:startup.tcl", line 72
at file "openocd_erase.cfg", line 12
I have also tested the exact same stlink and openocd version with a amd64 PC (Debian Linux) host, and Raspberry Pi 3 arm32 (rpi os). Everything works fine with these.
Any ideas as to what the problem may be here?
Thanks in advance.
Hi Mark!
On Tue, Nov 04, 2025 at 07:01:00AM -0000, Mark W wrote:
This doesn't look like something OpenOCD on arm64 specific, in fact,
it's widely tested and used on modern Arm devices. There must be
something else at play, probably even on hardware level. Is there
anything new appearing in dmesg when that error happens probably? Have
you tried starting OpenOCD without target connected to stlink?
Good you have those data points for reference. I would try comparing
strace logs for the working and non-working case, it might give
additional clues.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
This problem appears to be caused by a TI USB hub chip.
https://forums.raspberrypi.com/viewtopic.php?t=246248
There is no problem when I route around it, so I'll call this problem solved for the moment.
Thanks.
Last edit: Mark W 2025-11-05
On Wed, Nov 05, 2025 at 04:36:11AM -0000, Mark W wrote:
Hm, but this whole forum discussion doesn't seem to be related, and
it's all strange. They reference a forum post on TI E2E that confirms
that a certain USB hub model is full speed so naturally it doesn't
have any TT (transaction translators) from full/low speed to high
speed since it doesn't support any high speed connections at all. As
any other full speed hub by definition. So it's unclear why would
anyone even mention TTs in that context.
How did you route around it if you're talking about the USB hub
integrated on RaspberryPi 5 board? First of all, it's not a full speed
hub there (so the forum thread doesn't apply), second, as seen in
doc/usb_adapters/stlink/0483_3757_stlinkv3pwr.txt it's a high speed
device so no translation is needed in any case. Are you connecting it
via an additional full speed hub?
Now I feel even more confused than before and appreciate you
clarifying. It might help someone else facing similar issue later
who'd find this discussion via Internet search.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
It's a rPi CM5, with the TI USB hub on the parent PCB.
I understand how that would have been confusing, my apologies.
I'm not that familiar with openocd, or libusb. I'm just trying to fix the problem in front of me.
Last edit: Mark W 2025-11-05
On Wed, Nov 05, 2025 at 10:57:53AM -0000, Mark W wrote:
Thank you for clarifications.
So does it basically mean stlinkv3 might have issues working with full
speed? Can you try it with some other old (full speed) hub?
I wonder if old full speed hub IC is really that much cheaper than a
high speed one these days? USB2514B 4 ports high speed hub is $1.8
(buying 100) (and plenty other offerings) while TUSB2046 is $2.4 @100
(judging by Digikey). So where's the catch? ;)
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
If you are asking about the same issue in different forums, it is useful (and polite) to mention this and provide links. https://github.com/libusb/libusb/issues/1717
I've had massive problems with an LPC-Link2 CMSIS adapter on the black
USB 2.0 ports of a Raspberry Pi 4. It works flawlessly on the blue
USB 3.0 ports.
Best regards,
Daniel