I am using Data Center Software for debugging a USB device and I have questions about the USB STALL that occurs. Here is a block view of USB transactions from the device.
For more details, here is a screenshot of the transactions. The index numbers are different from the block diagram, but the sequence of the packets is the same.
- If it is from the device, is that packet a handshake packet?
- If the host generated that STALL, should I look at the endpoint data packets, ensuring they have the correct data format?
- Also, is it possible that STALL is the result of packets before the Control Transfer?
Thank you for your questions! There are many factors that could apply to how and why STALL occurs. First, we will provide cases of what could implement USB STALL, and then continue with details about the OUT txn STALL.
Instances of USB STALL
When an endpoint is halted, it indicates that the host-side code needs to apply some recovery action before communication over that endpoint can resume. The exact situation(s) under which this can happen are not defined in USB specifications. A possible cause is protocol violation.
The host can use the standard control messages get-status, set-feature and clear-feature to examine and manipulate the halted status of a given endpoint. Your concern however is how does the host become aware of the halt at endpoint 6. The following are two cases of when halts could occur:
Case 1 of USB STALL
The USB host client driver has endpoint information before the device has been configured, or during selection of an alternate setting. Also, it can iterate through all the interfaces, through each interface’s list of settings, and look at the properties of each endpoint or the entire set of endpoints in the setting. NOTE - Looking at the endpoint information does not affect the configured state of the device. This is the hosts internal implementation that is not visible on the USB bus.
Case 2 of USB STALL
A USB client driver communicates with its device by sending control transfers to the default endpoint - data transfers to bulk, interrupt, and isochronous endpoints of the device. Those transfers can fail due to various reasons, such as a STALL condition in the endpoint. If the transfer fails, the associated pipe cannot process requests until the error condition is cleared.
USB_CLEAR_FEATURE is applied on the Halted Endpoint. This case, however, is not what your data indicates. Most likely, the STALL under Case 1 is what is occurring in your USB setup.OUT Txn STALL Details
Here is a description of how OUT transaction STALL occurs.
- When the type of transaction is OUT txn, the data flows from the Host to the Device. In this case, the type of transaction is IN txn - the data flows from the Device to the Host.
- Since Index 18566 is directly under an OUT txn (STALL), that packet would have the same attributes as the parent transaction. In this case, the data flows from the Host to the Device.
This looks like an OUT transaction stall. A USB OUT transaction STALL occurs when a device responds to a USB OUT token with a STALL response. However, a USB IN transaction STALL occurs when a device responds to a USB IN token with a STALL response. In a typical USB OUT transaction STALL, a USB OUT token is followed by a DATAx frame, and the device responds with a STALL, ACK, NAK, or NYET.
We hope this answers your questions. Additional resources that you may find helpful include the following:
If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.