bulk传输bushound显示buffer overrun

bulk传输与buffer overrun

现象

调试usb设备的bulk数据传输时，通常用bushound查看上位机和设备间的数据交互。最近发现一个问题，上位机在读取数据时，读取失败，而bushound则显示buffer overrun，设备有时候也会死掉。

47.3  IN    f4 f5 f1 f0  00 00 00 00                            @P......                67.1.0        18:48:56.640  
47.3  USTS   c000000c                                            buffer overrun          68.1.0        18:48:56.671

到底是什么状况？bushound配置不对，仔细比对了网上的说法，没有发现工具配置的问题。

缘由分析

继续找，发现有前辈指出，上位机若是读取长度小于下位机上行的长度时，就会buffer overrun。好比，上位机ReadFile(80)，下位机假如按照64字节对齐，上行64+16就须要两个数据包，这就超出了范围，致使bushound显示buffer overrun。是否真是这个缘由？

因为调试所用的bulk模式，是不固定的带宽模式，因此可能会存在这种状况。通过调整，上位机读取时，按照64的整数倍长度读取，果真，再也不出现buffer overrun。 扩展一下，若是上位机读取长度大于下位机上行长度呢？网上有说上位机ReadFile不返回的，但实测，libusb提供的接口，读取较大的长度，能够返回。好比读取80，下位机实际只有8个字节，则返回8，并无挂着。

解决办法

统一上位机和下位机之间的数据传输格式，要么都用固定长度（如64字节）对齐，要么按照实际长度不对齐。节奏保持一致才不会出乱子。

bulk传输的注意事项

查找问题时，读到了MS的bulk传输注意事项：

1. bulk传输最好固定长度，速度更快

2. 若是带宽长度不够，很容易buffer overflows，极易丢失数据

参考

1. 实例1
2. 实例2
3. 微软关于bulk buffer overflows的描述