前言：stall 仅仅限于device 应答，而host端是不会发送stall握手包的。关于stall 包的场景，usb2.0 spec中有详细的说明。且收到stall后，软件必须做出相应的处理才能使通信恢复正常。

一级标题

一、STALL包分类：

参看usb2.0 spec，STALL包分为两类，一类是protocol STALL，一类是functional STALL。用通俗的话来说就是，当使用控制端点0时，对应的是使用的protocol STALL（虽然控制端点也可以作为functional STALL，但是spec 2.0 ch8.5.3.4 写了不建议这么做，我们也可以理解一般而言按端点这么划分开来）；当使用其他端点时，对应的表示functional STALL。

1.控制端点收到STALL

当使用的是控制传输时，如果device 无法完成host的指令，则返回stall 在控制传输的数据或者状态阶段，但是与第二类functional STALL不同，这种返回stall并不表示设备发生错误。如果当前的端点发送IN或者OUT包，端点在会持续返回STALL，直到收到一个新的SETUP控制传输为止。因此控制通道收到STALL应答的解决方法是重新开启一次控制传输。一般而言，这种情况下返回STALL表示请求或者参数不能被device识别。 ------ch8.5.3.4

2.数据端点收到STALL

如果是非0端点传输时，设备收到未被支持的或者无效的请求，相应端点设备在数据阶段或者状态阶段返回STALL，则这种情况下这个端点故障。此时，host应该通过控制端点0发送clear feature 指令来清除端点的Halt feature实现重新启用该端点。（halt的理解就可以理解为那些可以打开关闭可通过clear/set feature的端点）。

二、STALL包实例：

在测试usb U盘设备时，有的OUT端点不支持获取格式化容量指令，返回STALL。程序的处理流程为：先通过控制端点0发送clear feature指令重新启用被挂起的设备OUT端点，然后发送获取故障原因指令重新恢复运行。

参考资料：
理解halt:
https://blog.csdn.net/fudan_abc/article/details/1694092