2020年6月22日月曜日

STM32でDCCを作る方向で (24) Broken Pipe error発生中

STM32でDCCを作ろう!          INDEXページへ

だがDCC以前の問題で絶賛トラブル中.

前回の投稿で、USB setup dataの受信作法を知らなかったと反省しました.修正しました.でもまだどこかがおかしい...

packet anayzerでチェックすると、hostへの返信が勝手にスルーされちまっているようだ.どこでスルーされるかは不定で再現性なし.

wiresharkで採取できた「勝手にスルー場面の例」を以下に示す.

まずhostが発するsetupリクエストは例えばこれだ.(これには限らない)
byte列では[A1 01 00 01 00 12 04 00]
    bmRequestType: 0xa1    ←UAC request
    bRequest: 1
    wValue: 0x0100      ←現在のサンプリング周波数
    wIndex: 0x1200       ←clock sourceを指す
    wLength: 4      ←4bytes返信せよ
これを人間の言葉に直すと「サンプリング周波数を4bytesで返信してくれ」となる.

正常に返信できたらこうなる.Successで4bytesとなっている.
    Endpoint: 0x80, Direction: IN
    URB status: Success
    Data length [bytes]: 4
HEX dumpでは、64bytesのcontrol dataの後続に4bytesの返信dataが配置される.
  0000   80 47 bc 58 46 8c ff ff 43 02 80 14 02 00 2d 00
  0010   2b 99 f0 5e 00 00 00 00 4a fa 0c 00 00 00 00 00
  0020   04 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00
  0030   00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
  0040   44 ac 00 00

返信に失敗した場面ではこうゆう表示が出る.Broken pipeと言ってる.
    Endpoint: 0x80, Direction: IN
    URB status: Broken pipe (-EPIPE) (-32)
    Data length [bytes]: 0
HEX dumpでは、64bytes control dataはhostに辿り着いているが、後続の4bytesが消滅しているのだ.e0ffffffがBroken pipeを示している.
  0000   80 47 bc 58 46 8c ff ff 43 02 80 14 02 00 2d 00
  0010   2b 99 f0 5e 00 00 00 00 3f f8 0c 00 e0 ff ff ff
  0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0030   00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00
STM32がe0ffffffを出しているのだからSTM32の都合でBroken pipeを宣言していると考えてよいのだろう.ゆえに伝送路のbit errorではないと考えている.

STM32内部でBroken pipeがどのような原因で生じているのかを調査しまぁす.

fuckだなぁ

0 件のコメント:

コメントを投稿