You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For a bad Control Write Request (say an unrecognised SetSampleFreq) where the expected transaction sequence from host is as follows:
SETUP
OUT (Data stage)
IN (Status stage)
we currently would mark the control EP as halted after the SETUP, therefore responding to the OUT will a STALL (i.e the data stage)
The spec essentially defines two errors:
Device cannot fulfil the request - STALL the Status stage
Too much data is sent of requested from the device - STALL the Data stage
The spec is a little ambiguous in that in table 8-7 it states the the STALL is sent in the data phase when the function has an error. This seems to contradict the text.
My interpretation of the text is that in this case the device should accept the data stage but STALL the status stage.
Note, if we wish to stall reliably on too much data sent/requested we will probably need need to encapsulate the GetSetupBuffer() function further - GetControlData() for example. This would perform the checking and stall as appropriate.
Note, table 8-7 for "Control Read transfers" also reads "sent during the handshake phase". I assume this should be "sent during the status phase"
Ultimately this issue is probably low impact, a STALL is still issued from the device, just possibly at the wrong time. The end result is likely the same, that is the host moves to the next control request.
The text was updated successfully, but these errors were encountered:
For a bad Control Write Request (say an unrecognised SetSampleFreq) where the expected transaction sequence from host is as follows:
SETUP
OUT (Data stage)
IN (Status stage)
we currently would mark the control EP as halted after the SETUP, therefore responding to the OUT will a STALL (i.e the data stage)
The spec essentially defines two errors:
The spec is a little ambiguous in that in table 8-7 it states the the STALL is sent in the data phase when the function has an error. This seems to contradict the text.
My interpretation of the text is that in this case the device should accept the data stage but STALL the status stage.
Note, if we wish to stall reliably on too much data sent/requested we will probably need need to encapsulate the GetSetupBuffer() function further - GetControlData() for example. This would perform the checking and stall as appropriate.
Note, table 8-7 for "Control Read transfers" also reads "sent during the handshake phase". I assume this should be "sent during the status phase"
Ultimately this issue is probably low impact, a STALL is still issued from the device, just possibly at the wrong time. The end result is likely the same, that is the host moves to the next control request.
The text was updated successfully, but these errors were encountered: