Keil Logo

MDK MIDDLEWARE: USBH receive timeout after Clear Feature/ENDPOINT_HALT

Information in this knowledgebase article applies to:

  • USB Host component 6.x / custom class


When implementing custom class handling with the USB Host component, in case of device responding with STALL, it is needed to execute a Clear Feature/ENDPOINT_HALT using the function USBH_DeviceRequest_ClearFeature() to clear halt feature on an endpoint to be able to resume communication with that endpoint. An example is the Mass Storage Class and the recommended way to proceed after a STALL of data stage on Read TOC command.

After the Clear Feature request was executed, it is expected to read the command status on that endpoint. But this sometimes fails because the USB Host library generates a timeout on the next USBH_PipeReceive() from this previously cleared IN endpoint. What is the reason for this behaviour?


A possible reason is a Packet Identifier (PID) mismatch, which can be better explained by analysing the following image of captured USB traffic, where the DATA0/1 sequence for the data packets from IN endpoint 2 (EP02) is causing a PID mismatch for the host, which in this case ignores the received data with mismatching PID:

As last packet on IN endpoint 2 received by the host was DATA0 (Index 207), it still expects DATA1 on next IN endpoint 2 transfer, what does not happen (Index 233). So, host runs into a timeout (lot of IN-NAK at Index 235), as it expects to receive a DATA1 packet.

For the device, the DATA toggling gets reset on receiving the Clear Feature/ENDPOINT_HALT to send DATA0 next. But the host, which just sends a control packet containing the Clear Feature request, leaves its pipe DATA toggling status unchanged. This resulting discrepancy between device and host is leading to the PID mismatch and so causes the observed timeout.


An additional call of USBH_PipeReset() after USBH_DeviceRequest_ClearFeature(), which did the Clear Feature/ENDPOINT_HALT on the pipe assigned to the stalled endpoint, resets the host-expected data to DATA0. So the next USBH_PipeReceive() will be received correctly.


Last Reviewed: Thursday, June 2, 2016

Did this article provide the answer you needed?
Not Sure
  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.