GD32F405 USB主机与Android CDC设备通信冻结问题排查咨询

我的配置 #

• 硬件：GD32F405（兼容STM32）微控制器，USB FS主机模式，基于CMSIS直接操作寄存器
• 对接设备：Android VCP（虚拟串口）设备，设备描述符为基础CDC类（子类0、协议0、单配置），含BULK IN、BULK OUT、IRQ IN三个端点，仅使用BULK端点，以64字节包交换原始数据
• 通信协议：STX-ETX帧+ACK应答的轮询协议，未收到ACK则超时重传

问题现象 #

通信过程中随机出现Android设备停止接收主机数据：

• 数据包层面能收到设备ACK、DPID翻转正常
• 多次重试后OUT操作触发HALT标志，疑似Android设备未执行读操作导致类似ZeroWindow的事件
• 问题随机发生，发送/应答角色下均出现，偶发主机重传冻结、ACK丢失导致刷屏的情况

已尝试方案 #

• 并行轮询IRQ IN与BULK IN端点：仅初始几次收到数据，后续仅收到NAK
• 将payload限制为63字节（强制“最后一包”）：无效，20字节请求仍出现问题，排除包长度奇偶性问题

临时解决方案 #

通过重新初始化USB设备（总线复位→设置地址→选择配置）可恢复通信，但缓冲区会被清空，且数分钟后问题复现。对比验证：

• Android设备连接Linux主机无此问题
• 同一MCU配置对接STM32 CDC设备工作正常
  → 判定为GD32 USB主机实现与Android VCP的兼容性问题

可能原因 #

1. USB主机端BULK OUT事务的时序/握手处理不规范
   Android VCP对USB协议的容错性较低，GD32直接操作寄存器时，可能存在OUT事务完成后的握手信号（如ACK）处理延迟，或未正确处理设备返回的NAK/STALL状态切换，导致设备端接收缓冲区被占满后无法继续接收。
2. 缺少CDC类的IRQ端点交互
   Android VCP的底层实现可能依赖CDC IRQ端点的状态通知（如串口状态、流控信号），即使应用层未使用流控，设备端仍期望主机定期查询IRQ端点，否则会触发内部流控逻辑暂停接收。
3. USB主机的超时重传机制不符合规范
   自定义的超时重传逻辑可能过于激进，在设备返回NAK时未遵循USB协议规定的重试间隔，导致设备端接收队列溢出或进入异常状态。
4. GD32 USB主机控制器的FIFO/缓冲区管理问题
   直接操作寄存器时，可能未正确处理FIFO的空/满状态，或在事务切换时未清空残留数据，导致后续OUT包被错误截断或重复发送，触发设备端的错误处理逻辑。

排查步骤 #

1. 抓包分析USB总线事务
   使用USB协议分析仪抓取异常发生前后的总线数据，对比正常通信与异常时的事务序列：
   • 检查OUT事务的ACK/NAK/STALL响应时序
   • 确认设备端是否发送了Zero Window包（USB 2.0中BULK端点的零长度IN包表示接收窗口关闭）
   • 对比Linux主机与GD32主机的事务处理差异（如IRQ端点查询频率、OUT包间隔）
2. 补全CDC IRQ端点的定期查询
   按照CDC类规范，定期（如每100ms）向IRQ端点发送IN事务，即使不处理返回的状态数据，验证是否能解决设备停止接收的问题。注意处理IRQ端点返回的NAK，避免阻塞其他事务。
3. 优化重传机制与事务处理逻辑
   • 严格遵循USB协议规定的BULK事务重试间隔（至少等待一个帧时间，USB FS为1ms）
   • 当收到设备返回的NAK时，增加重试间隔的退避策略（如指数退避），避免频繁发送OUT包导致设备端过载
   • 检测到STALL标志时，先发送CLEAR_FEATURE请求清除端点HALT状态，再尝试恢复通信，而非直接重启设备
4. 检查GD32 USB主机寄存器配置
   • 确认USB主机的FIFO阈值、事务超时参数配置与STM32兼容（GD32兼容STM32，但部分寄存器默认值可能不同）
   • 检查OUT事务完成后的中断处理逻辑，确保及时释放主机控制器的资源，避免后续事务被阻塞
5. 验证Android设备的流控逻辑
   在Android应用中添加调试日志，监控VCP设备的接收缓冲区状态，确认是否因缓冲区满而触发暂停接收。若存在流控逻辑，可在主机端模拟发送DTR/RTS信号（通过CDC IRQ端点的SET_CONTROL_LINE_STATE请求），验证是否能恢复接收。

内容的提问来源于stack exchange，提问作者nv317