The STALL 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.
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.
How do I enable the legacy USB devices to be detected by a Type-C source ?
The general concept for setting up a valid connection between a Source and Sink is based on being able to detect terminations residing in the product being attached. To aid in defining the functional behavior of CC, a pull-up (Rp) and pull-down (Rd) termination model is used – actual implementation in hosts and devices may vary, the Figure below illustrates the model.
Initially, a Source exposes independent Rp terminations on its CC1 and CC2 pins, and a Sink exposes independent Rd terminations on its CC1 and CC2 pins, the Source-to-Sink combination of this circuit configuration represents a valid connection. As illustrated in the Figure above, only one CC pin is connected through the cable to establish signal orientation.
For example, below is the functional mode of an adapter that connect a Type-C source to a legacy device port. This adapter has a USB Type-C plug on one end plugged into the Source and either a USB Standard-B plug, USB Micro-B plug, USB Mini-B plug, or a USB Standard-A receptacle on the other end. The Pin A5 (CC) of the USB Type-C plug shall be connected to GND through a resistor Rd, and the recommended value of Rd in the Type-C specification is 5.1 kΩ ± 20%.
After connecting the legacy device to the Type-C source through the adapter, the source can detect the pull-down on the CC pin because of Rd, and then the source will turn on VBUS and VCONN.
Below is a prototype of the adapter to demonstrate the connection between a Type-C Source and a Legacy device port.
Connect the Pin A5 (CC) of the USB Type-C plug to GND through a resistor Rd (5.1 kΩ ± 20%), then connect Pin A6/A7 of the Type-C plug to D+/D- of USB Micro-B Plug.
All VBUS pins (A4 B4 A9 B9) and all Ground return pins (A1 B1 A12 B12) shall be connected together within the USB Type-C plug.
Connect a legacy device to the Type-C source through the adapter, it can be detected correctly, and also works well with the Type-C source.