The role of STALL handshake packet in USB transfer

by <a href="http://community.silabs.com/t5/Welcome-and-Announcements/Community-Ranking-System-and-Recognition-Program/m-p/140490#U140490"><font color="#000000"><font size="2">Hero Employee</font></font> </a> yucheng on ‎06-18-2017 08:42 PM

 

The STAL packet indicates that the endpoint has halted, or a control pipe does not support a certain request.

A function uses the STALL handshake packet to indicate that it is unable to transmit or receive data. Besides the default control pipe, all of a function's endpoints are in an undefined state after the device issues a STALL handshake packet. The host must never issue a STALL handshake packet.

 

Typically, the STALL handshake indicates a functional stall. A functional stall occurs when the halt feature of an endpoint is set. In this circumstance, host intervention is required via the default control pipe to clear the halt feature of the halted endpoint. Less often, the function returns a STALL handshake during a SETUP or DATA stage of a control transfer. This is called a protocol stall and is resolved when the host issues the next SETUP transaction.

 

As below is the captured USB bus data between an EFM8 HID device and Window PC USB host. The EFM8 HID device sends a STALL handshake in response to the get DEVICE_QUALIFIER descriptor request because the EFM8 HID device does not support the certain request. After that, the USB host will issue the next SETUP transaction.

 

STALL_win.png

 

Since the USB is a polled bus, meaning the host controller must initiate all transfers, so the behavior of USB transfers may depend on the USB host. As below is the captured bus data between the EFM8 HID device and MacOS PC, there is no any get DEVICE_QUALIFIER descriptor or other nonstandard request, so no STALL handshake can be found.

 

STALL_mac.png