Closed ryan-summers closed 8 months ago
This sounds right but ideally someone more familiar with the USB spec can weigh in.
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.
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.
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
)
I may be able to think about this in the next few days when I look at the ferrous USB device training course.
Thanks for taking a look! Was on vacation for the last week, but I appreciate the review! :)
Fixes #128 by updating the library to ignore
ep_in_status
on the EP0 control pipe when in theIdle
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.