だが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: INURB 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がどのような原因で生じているのかを調査しまぁす.
0 件のコメント:
コメントを投稿