Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixing an issue with windows device enumeration #129

Merged
merged 1 commit into from
Nov 1, 2023

Conversation

ryan-summers
Copy link
Member

Fixes #128 by updating the library to ignore ep_in_status on the EP0 control pipe when in the Idle state.

If the device gets a zero-length-packet while transmitting the last portion of an EP0-IN transmission, it will internally transition to the Idle state immediately and essentially "forget" that it just sent an EP0-IN packet, so it was erroring when getting an indication that this packet successfully transmitted.

@thejpster
Copy link
Member

This sounds right but ideally someone more familiar with the USB spec can weigh in.

@ryan-summers
Copy link
Member Author

Just to help clarify here because I know this is all really opaque (and I'm no USB-spec expert myself), but this arises as a result of the usb-device API not maintaining the order that IN, OUT, and SETUP tokens arrive on the USB bus, so this doesn't really impact any usage of the USB spec, but rather how we process our internal state.

@thejpster
Copy link
Member

Right but the spec will tell you what order you should expect things on the bus, and honestly I couldn't remember what the order was.

@ryan-summers
Copy link
Member Author

ryan-summers commented Oct 16, 2023

Right but the spec will tell you what order you should expect things on the bus, and honestly I couldn't remember what the order was.

Yeah I recognize that :) Just wanted to provide a bit more context.

In general, the spec says that you should get SETUP -> IN/OUT -> OUT packets | Send IN packets -> STATUS: https://www.beyondlogic.org/usbnutshell/usb4.shtml#Control

However, a number of USB stacks will actually not follow the standard method and terminate transfers early etc.

In our case, ep_status_in_complete just means that our last IN packet was transmitted successfully, so we can do the next one (or transition to Status)

@thejpster
Copy link
Member

I may be able to think about this in the next few days when I look at the ferrous USB device training course.

@ryan-summers
Copy link
Member Author

Thanks for taking a look! Was on vacation for the last week, but I appreciate the review! :)

@ryan-summers ryan-summers merged commit d6eaf93 into master Nov 1, 2023
3 checks passed
@ryan-summers ryan-summers deleted the rs/issue-128/usb-control-transfers branch November 1, 2023 14:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Devices may fail to enumerate on Windows (Part II)
2 participants