ＣＰＬＤ＋ＳＩＭＭを使ってＵＳＢプロトコルの解析を！
ＶＨＤＬを速習！　ＸＣ９５１４４ＸＬ＋１６ＭＢ・ＳＩＭＭを使ってＵＳＢプロトコルアナライザを作ってしまいました！
主目的は差し迫った事情からＵＳＢプロトコルの解析をすることだったのですが、その手段として選んだのがコレ！


［第４０回］


●Ｅｎｕｍｅｒａｔｉｏｎ　はじめから終わりまでの記録（８）ＧＥＴ＿ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）

前回までのところで、ホストから再度出されたＧＥＴ＿ＤＥＳＣＲＩＰＴＯＲ（ＤＥＶＩＣＥ）リクエストに応えてＰＩＣＷＲＩＴＥＲがＤＥＶＩＣＥ　ＤＥＳＣＲＩＰＴＯＲを送出したところまでを説明しました。
今回はその後の送受信についての説明です。
今までの説明と同様に、少しリストが重なりますが、前回までにお見せしたリストの最後のところから後ろのリストをお見せします。

0025806 SOF FNO=73C 0025806 PRE 0025811 IN ADRS=04 ENDP=00 DATA1 03 02 7F 7E 3B A0 F4 FE // DATA1 03 02 7F 7E 1B 50 7A 80 0025812 OUT ADRS=04 ENDP=00 DATA1 ACK 0025841 SETUP ADRS=04 ENDP=00 DATA0 80 06 00 02 00 00 09 00 GET_DESCRIPTOR CONFIG 0025842 IN ADRS=04 ENDP=00 NAK 0025844 IN ADRS=04 ENDP=00 NAK 0025845 IN ADRS=04 ENDP=00 NAK 0025847 IN ADRS=04 ENDP=00 DATA1 09 02 29 00 01 01 02 80 ACK 0025849 IN ADRS=04 ENDP=00 NAK 0025850 IN ADRS=04 ENDP=00 DATA0 32 C1 6A 3B A0 F4 1E 0025851 OUT ADRS=04 ENDP=00 DATA1 ACK

ＰＩＣＷＲＩＴＥＲからＤＥＶＩＣＥ　ＤＥＳＣＲＩＰＴＯＲが送出されてホストがそれにＤＡＴＡ１で応えたあと、ホストからはＧＥＴ＿ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）リクエストが出されます。
８０　０６　００　０２　００　００　０９　００　です。

最初の　８０　０６　はＧＥＴ　ＤＥＳＣＲＩＰＴＯＲです。
次の　００　０２　はその要求がＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲを要求していることを示しています。
コード　０２はＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲを示していて、００　はＩＮＤＥＸです（この場合には００になります）。
次の　００　００　はリクエストによって意味が異なりますがこの場合には　００　００　です。
最後の　０９　００　は要求しているＤＥＳＣＲＩＰＴＯＲの長さ（バイト数）が９バイトであることを示しています。

ホストから送出されたＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）リクエストに対して、端末は要求に応えてＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲを送ります。
０９　０２　２９　００　０１　０１　０２　８０　です。

ディスクリプタの最初の１バイトはそのディスクリプタの長さを指定します。
ここでは０９ですから９バイトであることを示しています。
ディスクリプタの２バイト目は、そのディスクリプタの種類を示しています。
このディスクリプタがホストから要求されたＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲ（コード０２）であることを示しています。
次の　２９　００　はＣＯＮＦＩＧＵＲＡＴＩＯＮ，ＩＮＴＥＲＦＡＣＥ，ＥＮＤＰＯＩＮＴの各ＤＥＳＣＲＩＰＴＯＲを合計した全バイト数です。
２９Ｈ＝４１ですから全体では４１バイトあることを示しています。
次の１バイトはＩＮＴＥＲＦＡＣＥ　ＤＥＳＣＲＩＰＴＯＲの個数（このリストでは０１）です。
その次の１バイトは複数のＣＯＮＦＩＧＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲがあるときにその番号（このリストでは０１）です。
しかし複数のＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲってなんじゃいな？という疑問があります。
よくわかりませぬ。
次の１バイトはＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲのＳＴＲＩＮＧ　ＤＥＳＣＴＩＰＴＯＲ　のＩＮＤＥＸ（このリストでは０２）です。
そもそもＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲのＳＴＲＩＮＧ　ＤＥＳＣＴＩＰＴＯＲ　って何なんでしょう。
これもよくわかりませぬ。
８バイト目はビット７〜５までに意味があります。ビット４〜０はリザーブされています（全ビット：０）。
このリストでは８０ですから、ビット７＝１でそれ以外は０です。
ビット７＝１はＵＳＢバスラインから＋５Ｖ電源を取ること（バスパワー）を指定しています。
ビット６は自己電源の指定です。
ビット５はリモートウェイクアップの指定です。

ＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲは９バイトですから、最後の１バイトは２回目の送信データになります。
上のリストでは下から４行目の先頭にある　３２　です。
この１バイトはバスパワーを使う場合の最大消費電流です。
２ｍＡ単位で指定します。
このリストでは３２Ｈですから５００ｍＡということになります。
これはＵＳＢ２．０規格での最大値になります。

この最後の１バイトの後ろの２バイトは前回説明しましたＤＥＶＩＣＥ　ＤＥＳＣＲＩＰＴＯＲの最後の２バイトの後ろと同じで、
ＣＲＣ１６（巡回冗長検査）です。
ＣＲＣ１６の２バイトの次には、前回と同じでプログラムでは検出できなかった何かがかくれているようです。
そこで前回同様手作業で解読をしてみました。
その結果はこれも前回と同じで、ＳＹＮＣに続いてＡＣＫが出現しました。

3B A0 F4 1E 11011100 00000101 00101111 01111000 | | SYNC ACK

これで前回と同様、情報が完全につながりました。
ホストはＰＩＣＷＲＩＴＥＲから送られたＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲの最後の１バイト（とＣＲＣ１６）を受け取ると、それにＡＣＫを返したあと、ＤＡＴＡ１を送出してＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲの受信を完了しました。

ちょっとわかりにくいかも知れませんが、上で説明しましたようにＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲは９バイトですが、本当はこれに続いてＩＮＴＥＲＦＡＣＥ　ＤＥＳＣＲＩＰＴＯＲ、ＥＮＤＰＯＩＮＴ　ＤＥＳＣＲＩＰＴＯＲを送出することになっています。
ＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲを含めた総バイト数は２９Ｈ（４１バイト）である、とＣＯＮＦＩＧＵＲＡＩＯＮ　ＤＥＳＣＲＩＰＴＯＲの３、４バイト目に記述しています。
しかしホストから出されたＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）リクエストで要求しているバイト数は９バイトなので、ＰＩＣＷＲＩＴＥＲはＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＤＥＳＣＲＩＰＴＯＲの９バイトのみを送出し、ホストもその直後にデータ受信完了のマークとしてＤＡＴＡ１を送っています。
実はＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＣＯＮＦＩＧＵＲＡＴＩＯＮ）リクエストはこれで終わりではなくて、この後のところでも出されています（次回以降で説明の予定）。
そういうところがＥＮＵＭＥＲＡＴＩＯＮ手続きのややこしいところで、したがってそれに応えるためのプログラムも複雑にならざるを得ないのです。

ＣＰＬＤ＋ＳＩＭＭを使ってＵＳＢプロトコルの解析を！［第４０回］
２０１４．４．１０ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る