USB 端点 STALL 与 Bulk 传输超时：动固件之前先看抓包

枚举跑通之后，USB 设备还是会以各种让应用开发者摸不着头脑的方式翻车：Bulk 读超时、写一直不结束、HID 报告不来了、主机报端点 STALL。这些故障经常被当作驱动 bug 或随机的固件 hang，但一份抓包通常能更快地圈出问题范围。

端点层的故障是数据通路的证据。它们发生在主机已经"认识"设备之后——也就是描述符正确，端点行为也未必对。

STALL 是信号，不只是错误

USB 端点可以返回 STALL 来表达"我处理不了这个请求"或者"这条类/厂商命令我不支持"。在类请求里，控制端点的 STALL 可能是合理的——前提是请求本身就无效。但数据传输端点在正常传输流里出现 STALL，通常就得仔细查。

抓包时要回答：

• 哪个端点 STALL 了？
• 是 Control、Bulk、Interrupt 还是 Isochronous？
• STALL 之前是什么请求或传输？
• 主机有没有 Clear Halt？
• 发完 CLEAR_FEATURE(ENDPOINT_HALT) 之后流量有没有恢复？
• 这个 STALL 是固件主动响应不支持的命令，还是误判？

没有这些上下文，"端点 STALL 了"这个描述就太空，没法下手。

Bulk 超时要分清方向和队列上下文

Bulk 传输超时的原因可能有很多：

• 主机期望 IN 数据，但设备还没准备好
• 设备期望 OUT 数据，但应用已经停写
• 固件端点缓冲区没有 Prime
• 主机驱动提交的读长度大于固件实际支持
• 设备一直 NAK 到超时
• 端点地址或方向配错
• 前一次 STALL 没有被清掉

第一件事就是分清方向。Bulk IN 超时和 Bulk OUT 超时是两种不同的情况。IN 方向：设备有没有真的回过数据？OUT 方向：主机有没有发数据，设备有没有 ACK？

描述符正确只是必要条件

描述符正确声明了一个 Bulk IN 端点，设备仍然可能回不出有效数据。CDC 设备枚举成串口，也照样可能忽略 Line Coding 或控制线状态。厂商自定义接口把端点暴露出来，却可能在数据流起来之前需要先执行一条初始化命令。

所以端点调试必须把以下几样东西拼在一起：

• 描述符证据
• 类或厂商的 setup 请求
• 传输方向
• payload 长度
• 状态结果
• 时序和重试行为

抓包应该能告诉你：是主机提了不合理的要求，还是固件没能完成一个合法请求。

固件团队要"修前+修后"各抓一份

端点相关的 bug，"修改前 + 修改后"各抓一份包特别有价值。第一份包证明故障确实存在，第二份包证明修好了。一个好的对比应该展示：

• 同一台设备、同一个配置
• 同样的端点地址
• 同样的主机请求模式
• 旧抓包 STALL 或超时
• 新抓包完成传输、payload 符合预期

这能让固件回归评审顺畅很多。客户报"USB 莫名其妙卡住"的时候，支持团队也能拿到一份可复现的工件。

Bus Scope 在这个场景里做什么

Bus Scope 的目标是 USB 证据，不是把所有协议都装进来。在端点 STALL 和超时的场景下，它把包细节、端点元数据、原始字节、传输类型、类解读这几样东西放在一起。

有用的输出包括：

• 端点和方向
• 传输类型
• 失败前的请求或传输
• 状态证据
• 失败点附近的原始 payload
• 这个问题是跟着枚举、类初始化、还是应用流量来的

这些就是固件工程师在动手改端点缓冲区逻辑或者主机侧重试行为之前需要看到的东西。

你搜 "USB Bulk 传输超时" 或 "USB 端点 STALL" 的时候，第一步不要重写整条设备栈。先抓端点证据。