USB Endpoint Halt 恢复：CLEAR_FEATURE、STALL 循环、Bulk 失败与驱动 Reset 行为

USB Endpoint Halt 是"设备能用一次，然后挂掉"这类 bug 的常见来源。一次 Bulk 传输 STALL，驱动 Clear Halt，设备又 STALL，最后应用报超时、I/O 错误、设备 Reset 或断连。用户搜 "USB endpoint halt"、"CLEAR_FEATURE ENDPOINT_HALT"、"USB STALL loop"、"bulk endpoint stalled"、"libusb clear halt" 的时候，设备其实没有干脆消失，只是某条端点不肯再收发流量了。

Bus Scope 在这个场景下有用，因为 Endpoint Halt 恢复是一个序列，不是一个孤立事件。你需要看到第一次 STALL、主机的恢复请求、设备之后做了什么，以及是不是同一条命令再次触发了 STALL。

Endpoint Halt 是什么

Endpoint Halt 意味着该端点被卡住，Halt 条件被清除之前不能继续正常传输。主机可能发：

CLEAR_FEATURE(ENDPOINT_HALT)

给受影响的端点。在此之后，endpoint data toggle 和设备端的状态需要保持一致，传输才能正确恢复。

如果固件只清了 USB 硬件标志，没清自己的协议状态，下一笔传输很可能又挂。

STALL vs 超时

STALL 是显式的拒绝。超时是指在预期时间内没收到完成。超时可能因为端点根本不应答、设备一直 NAK、或者设备断连了。

Endpoint Halt 恢复从一次 STALL 开始。如果主机没看到 STALL、只看到超时，恢复路径就不一样。

Bulk Endpoint Halt

Bulk 端点常在命令非法、协议阶段错位、固件检测到错误的时候 Halt。

例子：

Host -> Device bulk OUT command
Device -> Host STALL on bulk IN
Host -> Device CLEAR_FEATURE(ENDPOINT_HALT)
Host retries bulk IN
Device stalls again

这个模式说明 Endpoint Halt 是设备协议状态的症状，不是一次性的总线错误。

恢复要匹配端点方向

端点地址包含方向。0x81 和 0x01 是不同方向。Clear 错了端点，恢复不了这条死掉的 pipe。

要查：

• 哪个端点 Halt 了？
• 方向是 IN 还是 OUT？
• 主机清的是不是同一条端点？
• Clear 之后传输有没有恢复？
• Data Toggle / 状态有没有正确恢复？

"Clear Halt 没用"这种抱怨里，很大一部分其实是清错了端点。

反复 STALL 循环

Clear 之后还是反复 STALL，通常意味着根本原因没消除：

• 主机又发了同一条设备不支持的命令
• 固件状态机还卡在错误里
• 设备期待先 Reset 再重试
• 主机从错误的端点读
• 命令长度或校验和不对
• 端点 Data Toggle / 状态不一致
• 固件要求一条类 / 厂商请求之后才肯恢复

Trace 应该把第一次 STALL 之前的命令也包含进来，而不是只盯着恢复动作。

驱动的 Reset 行为

Clear-Halt 恢复失败的话，驱动可能会 Reset 设备。这会把原始的端点错误盖掉。用户看到的是重连或者设备消失，但总线证据显示最早那次失败的根因其实是一个 STALL 循环。

保留这条时间线：

1. 最后一笔成功的命令
2. 第一次 STALL
3. Clear Halt 尝试
4. 重试
5. 反复 STALL 或超时
6. 设备 Reset 或断连

排查清单

按这个流程：

1. 定位 STALL 的端点
2. 记录端点方向和传输类型
3. 看 STALL 之前的那笔命令或传输
4. 看主机有没有发 CLEAR_FEATURE(ENDPOINT_HALT)
5. 确认目标端点是对的
6. 看传输有没有恢复
7. 如果 STALL 反复出现，检查固件协议状态
8. 看恢复失败后有没有发生设备 Reset
9. 对比已知正常的命令序列
10. 在 STALL 之前保留足够的上下文

最终诊断

USB Endpoint Halt 恢复是一个状态机问题。CLEAR_FEATURE(ENDPOINT_HALT) 可以清掉 USB 端点条件，但不会自动修好固件协议状态、非法命令、错误的端点或驱动的重试逻辑。

Bus Scope 把完整的 Halt 和恢复序列摊开来——端点故障可以从真实的 USB 行为出发诊断。