USB Bulk 传输超时：High-Speed / Full-Speed / STALL / NAK / 固件延迟排查
USB Bulk 传输超时、读慢、写 STALL、NAK 行为、端点 Halt 恢复、速度不匹配、固件延迟的排查，配套 USB 抓包证据。
USB Bulk 传输用在"正确性比固定时序更重要"的场景。存储设备、串口适配器、调试探针、固件升级器、扫描枪、厂商自定义设备、很多数据采集产品都用 Bulk 端点。它们挂的时候，用户搜 "USB bulk transfer timeout"、"bulk endpoint stalled"、"USB read timeout"、"USB write timeout"、"libusb bulk transfer failed"、"USB device stops responding during bulk transfer"。
应用那边通常看到超时或 I/O 错误。总线可能讲的是更丰富的故事：设备 NAK 太久了、端点 STALL 了、主机重试了、设备 Reset 了、传输大小不对、设备速度低于预期、固件在准备数据时阻塞了。
Bus Scope 在这个场景下有用，因为 Bulk 传输的失败需要端点级的证据，而不是应用栈的一个堆栈。
Bulk 传输擅长什么
Bulk 传输在 USB 协议层是可靠的。它们用剩余带宽，能重传。适合"对延迟要求不那么严、对正确性要求高"的大数据搬运。
常见的 Bulk 设备：
- USB 大容量存储
- CDC 串口适配器
- 厂商自定义固件工具
- 调试探针
- 测量设备
- 打印机和扫描枪
- 部分采集设备
- FPGA 或微控制器的数据管道
Bulk 用的是剩余带宽，性能会受其他 USB 流量和主机调度影响。
超时不一定等于丢包
Bulk 传输超时通常意味着主机侧的请求在应用超时内没完成。USB 总线即使合法也可能发生这种情况。
原因包括：
- 设备还没准备好数据、一直 NAK
- 固件忙、延迟了响应
- 端点 STALL 之后被 Halt
- 主机把请求发到了错的端点
- 传输大小和协议预期不符
- 设备 Reset 或断连了
- 驱动没正确提交传输
- Full-Speed 通路对预期吞吐来说太慢
- 另一台设备把总线带宽吃光了
- 应用超时太激进
Trace 应该能展示上面哪种情况最有可能。
NAK 行为
USB 设备可以用 NAK 表示"我暂时没准备好"。NAK 不一定是错误，它是流控信号。
对 Bulk IN 端点，反复 NAK 可能意味着设备还没数据。对 Bulk OUT 端点，NAK 可能意味着设备暂时接不下更多数据。
问题在持续时间和上下文。少量 NAK 是正常的。一直 NAK 到应用超时，要么设备永远没准备好，要么主机要数据的时间点就不对。
STALL 和端点 Halt
STALL 和 NAK 不一样。它通常意味着端点 Halt 了，或者请求在那个上下文里不被支持。恢复通常需要：
CLEAR_FEATURE(ENDPOINT_HALT)
主机如果不 Clear Halt，后面的传输就可能一直挂。如果 Clear 之后又立刻 STALL，设备固件可能就在拒绝命令序列。
要看：
- 超时之前的第一次 STALL
CLEAR_FEATURE(ENDPOINT_HALT)- Clear 之后传输有没有恢复
- 是不是每次都是同一命令触发 STALL
- 反复 STALL 之后的 Reset
High-Speed vs Full-Speed 的预期
USB 速度决定了"实际能跑多少吞吐"。Full-Speed 设备不可能跑出 High-Speed 吞吐。High-Speed 设备可能因为线材、Hub、端口、信号完整性、设备协商而降级。
应用如果假设 High-Speed 性能、但设备枚举成 Full-Speed，大传输就可能超时。
查描述符、协商速度、端点 Max Packet Size、实际传输节奏。不要从接口形状或宣传标签去猜速度。
固件命令协议
很多 Bulk 设备在 USB 之上实现了一套命令 / 响应协议。主机往 Bulk OUT 写一条命令，等 Bulk IN 上的数据。
超时的原因：
- 命令格式错
- 设备在 Bulk 传输之前先要 Control Request
- 设备在另一个端点上发状态
- 主机读得太早
- 主机读得太多
- 固件处理命令时阻塞了
- 设备要求零长度包边界
- 之前的错误状态没清掉
包证据能展示设备到底是：忽略了命令、STALL 了、接受了但没回、还是回了但走的是另一个端点。
Bulk 传输大小和短包
USB Bulk 协议常用短包来标识传输结束。主机如果期望固定长度但设备发的是短包，应用可能把结果解错。设备其实已经结束传输，但主机还在等更多数据，应用层就会超时。
要看：
- 请求的传输长度
- 实际返回的长度
- 短包
- 零长度包
- USB 之上的协议框定
这点在自定义固件和 libusb 工具里特别重要。
排查清单
按这个流程：
- 抓枚举和端点描述符
- 确认设备速度和端点 Max Packet Size
- 识别 Bulk IN 和 Bulk OUT 端点
- 抓超时的那笔命令或传输
- 看端点回的是 NAK、STALL、数据、还是断连
- STALL 的话看
CLEAR_FEATURE(ENDPOINT_HALT)的恢复 - 对比请求长度和实际长度
- 看设备有没有发短包或零长度包
- 对比直连端口 vs Hub、High-Speed vs Full-Speed 通路
- 能拿到固件日志的话和总线抓包对照
最终诊断
USB Bulk 传输超时不是一种 bug。它可能意味着：正常的 NAK 行为超出了应用超时、端点 STALL 没恢复、固件没回、速度低于预期、协议框定错了、设备 Reset 了。
Bus Scope 把端点级序列摆出来——超时变成了可诊断的 USB 证据，而不是一个泛泛的 I/O 错误。