Yes, Antonio, your understanding is correct. I've tried moving to different USB buses, which fixes this issue. However, I need all my devices to be plugged into the same programmable USB hub, which can do a power-on-reset when I'm working remotely.
dmesg def spits out a bunch of errors about not being able to talk to the USB device under test. Linux tries disconnecting, power cycling and the USB locks up around the `xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command` message. Unfortunately I'm not familiar with linux programming. Berk, everything is sturdy and it's definitely a software issue with a 100% repro rate. I agree with Chris, this workaround is no-risk/no-effort. --- ** [tickets:#343] Increase CMSIS_DAP usb timeout value** **Status:** new **Milestone:** 0.10.0 **Created:** Fri Mar 18, 2022 10:08 AM UTC by Gabor **Last Updated:** Sun Mar 20, 2022 08:24 PM UTC **Owner:** nobody The linux USB stack locks up for 5 seconds if there's an unreponsive USB device, while linux is trying to reconnect. If I halt my device under test, it causes the above linux usb stack bug and my openOCD connection with my DAPLink breaks. The best solution I've found is increasing the USB_TIMEOUT to 6000ms in cmsis_dap.c. What do you think about submitting this fix? If there's an easy way for me to create the CL, I'm happy to do so. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
