2

古いシリアル ポートを報告する単純な仮想シリアル ポート デバイスを作成しています。この時点で、デバイスを列挙し、文字を送受信できるようになりました。

ホストからデバイスへのさまざまな数のバルクアウト送信の後、エンドポイントはあきらめてデータ転送を停止したように見えます。PC 側で書き込みエラーが発生し、USBlyzer トレースから判断すると、音楽がストール (USBD_STATUS_STALL_PID) で停止します。ただし、私のコードはそのエンドポイントで意図的に STALL 条件を発行することはなく、生成されたステータス フラグは決して設定されません。

リクエストの発行と STALL の間の経過時間が短い (<300 µs) ことを考えると、タイムアウトではなく、何らかの無効なレスポンスのように見えます。デバイス側では、バッファ内のデータと適切な DATA0/1 同期により、出力エンドポイントの準備が整いましたが、それ以上何も起こりません。

「大量の」データの送信を開始するまで、デバイスは長時間でも正常に動作しているように見えることに注意してください。私が知る限り、デバイスの列挙/構成も正常に完了したようです。ああ、バルクイン エンドポイントはこの後も問題なく動作し続けます。

記録のために、私は標準の Windows usbser.sys ドライバーと XMega128A4U µP を使用しています。また、複数の Windows Vista および 7 マシンで同じ動作が見られます。

私が間違っていること、または物事を絞り込むためにさらにどのようなテストを実行する可能性があるかについてのアイデアはありますか?

USBlyzer ログ、 USB CDC スタック、 テスト プロジェクト

4

2 に答える 2

3

記録のために、これは最終的に発振器の問題であることが判明しました。（1,000 HzのUSBフレームが選択されている場合でも、FLLの参照は常に1,024 Hzであるようです。わずかなクロックエラーは、パケットに1ビットが多すぎるとパケットが拒否されることがあることを意味します。）

話の教訓は、高レベルのプロトコルに問題があると想定する前に、基本を確認することだと思います。また、振り返ってみると、ハードウェアUSBアナライザーは価値のある投資でしたが、ソフトウェアの代替手段は、問題が発生したときに一般的なエラーコードを吐き出すか、まったく吐き出さないようです。

于 2012-11-24T22:31:56.457 に答える
2

ホスト側で出力バッファのオーバーフローが発生すると、out-endpoint の停止が発生する場合があります。デバイスが out-endpoint 経由で受信したデータをフェッチすることを確信していますか? もしそうなら、少なくともデータがデバイスに送信されるのと同じ速さでデータをフェッチしますか?

「大量の」データの送信を開始するまで、デバイスは長時間でも正常に動作しているように見えることに注意してください。

これは、出力バッファのオーバーフローのヒントのようです。

于 2012-11-12T20:49:02.847 に答える