USB 设备反复断开：Reset 循环、电源事件与枚举失败排查

USB 设备反复断开是最让人头疼的硬件问题之一——症状吵、不一致。设备出来、消失、重连、COM 端口变、枚举失败、或者能用几秒然后 Reset。用户搜 "USB device keeps disconnecting"、"USB reset loop"、"USB device not recognized after reconnect"、"why does my USB device re-enumerate"——因为操作系统的提示几乎不会告诉你真正发生了什么。

有用的证据在应用层之下。你需要知道：是主机 Reset 了端口、设备停止应答、描述符读失败、电源管理挂起了设备、驱动发了一条类请求、还是端点 STALL。

Bus Scope 就是为这种 USB 排查风格造的。它把 USB 当黑盒看待是不行的，要看 Control Transfer、描述符读、Reset、端点行为，以及断连前后的时序。

"断开"可能意味着什么

"USB 断开"这个词其实描述了好几种不同的故障：

• 物理拔掉或线材抖动
• 电气噪声或供电不稳
• 主控制器端口 Reset
• 设备固件崩溃并重启
• Reset 之后枚举失败
• 驱动卸载再加载
• Selective Suspend 或运行时电源管理
• 端点 STALL 之后恢复失败
• 组合设备接口失败
• 高带宽传输过载

这些在桌面通知里看着差不多，在 USB 证据里看着完全不一样。

枚举 Reset 循环

Reset 循环常常是这样：主机检测到设备、Reset 端口、读描述符、分配地址、在 Configuration 完成之前失败。循环重复。

简化版的序列：

Port reset
GET_DESCRIPTOR device
SET_ADDRESS
GET_DESCRIPTOR configuration
SET_CONFIGURATION
Disconnect
Port reset
GET_DESCRIPTOR device
...

如果设备在 SET_CONFIGURATION 之前就挂，问题可能在描述符内容、固件时序、供电、或主机兼容性。如果在之后才挂，问题可能在类初始化、端点配置、或者驱动请求。

供电问题可能伪装成协议问题

电压跌落、电流尖峰、Hub 供电不足都会让 USB 设备 Reset。这在以下场景很常见：

• USB 摄像头
• USB 采集卡
• 外接硬盘
• 开发板
• 蜂窝 Modem
• 走被动 Hub 的设备
• 长或低质量的线材

在包层面，供电相关的 Reset 可能看起来是：突然沉默，然后重新枚举。设备停止应答请求，主机 Reset 端口，枚举重新开始。

Bus Scope 不能直接测电压，但能展示 Reset 前后 的时序和序列。如果最后一笔成功操作是高带宽 stream-start 或电机 / 电源模式命令，证据就指向供电或固件压力。

Selective Suspend 和运行时电源管理

操作系统可能挂起空闲的 USB 设备省电。设备和驱动正确支持时这是正常的。设备固件不能干净地 Resume、或者驱动挂起了应用以为会一直在线的设备，就成了问题。

症状包括：

• 刚插上能用，空闲一会儿就坏
• 空闲之后的第一笔请求报错
• 休眠或锁屏之后设备消失
• 串口设备 Resume 之后状态变了
• HID 设备 Wake 之后输入丢失

USB trace 能看出流量是不是在故障之前就停了、是不是发生了 Resume/Reset 序列。这比从应用错误消息猜要靠谱。

断开前的端点 STALL

有些断开报告其实是端点级的失败。设备可能 STALL 一个 Bulk 端点、Interrupt 端点、或 Control 请求。驱动尝试 Clear Halt，恢复失败的话，驱动 Reset 设备或应用关掉句柄。

要看：

• Control Transfer 上的 STALL
• 反复失败的 Bulk 传输
• CLEAR_FEATURE(ENDPOINT_HALT)
• 同一请求每次都触发 Reset
• 断连前超时

同一命令总是触发 Reset，设备固件可能在处理那条命令时崩了。

组合设备的 Reset 循环

组合 USB 设备在一台设备下暴露多个接口。比如：

• CDC 串口接口
• HID 控制接口
• 大容量存储接口
• 厂商自定义诊断接口

设备可以部分枚举，但某个接口驱动挂上来的时候失败。用户可能看到 "USB device recognized" 紧跟着立即断连——因为某个接口触发了固件崩溃或驱动冲突。

在 trace 里检查 Interface Descriptor、Alternate Setting、Endpoint Descriptor、类特定请求。Reset 可能只在主机开始配某个具体接口之后才发生。

高带宽设备

USB 视频、音频、采集、数据采集设备可能负载一上来就断。设备可以正常枚举、能过简单的 Control 请求，但流起来就挂。

常见原因：

• Isochronous 带宽预留失败
• Bulk 端点超时
• 主控制器带宽压力
• Hub 瓶颈
• USB 2.0 vs USB 3.x 模式不一致
• 固件 buffer 溢出
• 驱动选了不支持的 Alternate Setting

断连发生在 stream-start 请求或 Alternate Setting 切换之后的话，看 Reset 之前的那笔具体传输。那常常是最重要的线索。

抓什么

对可复现的断开，从插入前或失败动作前开始抓。要看的是完整故事：

1. 设备 Attach
2. 端口 Reset
3. 描述符读
4. 地址分配
5. Configuration 选择
6. Interface 驱动请求
7. 第一次正常的应用传输
8. 失败前的最后一笔成功传输
9. 超时、STALL、Reset 或断连
10. 失败后的重新枚举

设备已经挂了才开始抓，会丢掉最重要的证据。

排查清单

按这个顺序：

1. 用一条短的、已知正常的线复现
2. 第一次测试避开被动 Hub
3. 从插入开始抓枚举
4. 看故障是在 SET_CONFIGURATION 之前还是之后
5. 识别最后一笔成功的请求
6. 找 STALL、超时和反复的 Reset
7. 对比空闲故障 vs 负载故障
8. 试另一个 USB 端口或主控制器
9. 收集完证据之后再考虑关掉 Selective Suspend
10. 能比的话对比同一台设备在另一个 OS 上的表现

最终诊断

"USB device keeps disconnecting" 是一种症状，不是根因。修法取决于证据指向的是：供电不稳、固件 Reset、描述符失败、驱动类请求失败、端点 STALL、Suspend/Resume 故障、还是高带宽过载。

Bus Scope 把故障前后的 USB 事务摆出来——你可以不再从桌面通知里猜，而是从真实的总线行为出发做调试。