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に2つのパケットが必要となり、範囲を超えてbushoundにbuffer overrunが表示される.本当にこの原因ですか?
デバッグに使用するbulkモードは、固定されていない帯域幅モードであるため、このような場合がある可能性があります.調整を経て、上位機読取時に64の整数倍の長さで読み取ると、やはりbuffer overrunは発生しません.拡張して、上位機の読み取り長さが下位機の上り長さより大きいとしたら?ネット上では上位機ReadFileは返さないと言われていますが、実測ではlibusbが提供するインタフェースは、大きな長さを読み取って返すことができます.たとえば80を読み取ると,下位機は実際には8バイトしかないので,8を返し,掛けていない.

解決策

上位機と下位機の間のデータ転送フォーマットを統一するには、64バイトなどの固定長で位置合わせするか、実際の長さで位置合わせしないかのいずれかです.リズムが一致してこそ混乱しない.

bulk転送の注意事項

問題を探している間に、MSのbulk転送の注意事項を読みました.

bulk伝送は最良の固定長であり、速度はより速い

である.

帯域幅の長さが足りなければbuffer overflowsが容易であり、データの損失が極めて容易である

リファレンス

例1

例2

マイクロソフトbulk buffer overflowsについての説明