unexpected clear halt on bulk in following stall
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by reading the implementations of libusb_bulk_transfer and libusb_clear_halt, then trace the Windows libusbK backend behavior described in the report. Reproduce the sequence on Windows 11 with libusb 1.0.29 and compare the USB capture around the explicit clear and the next bulk IN request. Done means identifying whether the extra clear is initiated by libusb and documenting or fixing the behavior so the queued data is not dropped.
Written by the indexing model from the issue text.
Description
Host OS win 11 static mingw64 libusb 1.0.29 using libubsk backend
i'm handling the target device firmware and host pc software actually validating and debugging error reporting and behavior both side .
The scenario is the device has an error it set halt on end point so that next request from pc stall and host to take any action.
device f/W wait on halt condition to get clear before to continue streaming and queue next data chunk .
On pc eror is seen and i end up using clear end point feature ( clear halt) what trigger the data streaming restart on device side .
libusb_bulk_transfer(...) return 0 (app frame 0)
libusb_bulk_transfer (...) return -9 (was app frame 1)
libusb_clear_halt(..)
f/w see it and restart queuing data
libusb_bulk_transfer(...) return 0 (get frame 4 when expecting frame 3 frame )
Unfortunately after in pc software I do clr halt in purpose , my next usb bulk in request does too issue a clear endpoint feature halt on my behalf .
If i don't initiate myslef clr halt i only see once on bus thus confirming the 2nd clear from bulk request.
See capture below (interactive debug why slow 10s between each request)
This is annoying in my application as i need timely controlled clear halt.
This extra clr is not welcome has it cancel/drop data already queued by the device f/w (di already took action and queued new data after first clear halt) what cause unacceptable data drop and issue in the application
Is libusb initiating this on it's own ? is it libusbk backend ?
How can i prevent it ?
- Dominant language
- C
- Stars
- 6.2k
- Forks
- 2.1k
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from libusb/libusb
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
-
android core
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Windows version of libusb-master (MSVC build) can't be built when git installed w/o bashPossibly taken @Youw claimed this 20 days ago. Openwindows
-
windows
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
core enhancement
Difficulty 5/5 Over a week Newbie friendliness 30/100
Similar issues
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 85/100
FujiNetWIFI/fujinet-lib#122 · 1 comment ·
Maintainers usually reply within 1 day
-
bug format I/O medium priority rt_lib
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
compiler-explorer/compiler-explorer#9272 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
semantic-reasoning/wirelog#2163 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 3 days