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的描述