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