2014.4.10

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

CPLD+SIMMを使ってUSBプロトコルの解析を!
VHDLを速習! XC95144XL+16MB・SIMMを使ってUSBプロトコルアナライザを作ってしまいました!
主目的は差し迫った事情からUSBプロトコルの解析をすることだったのですが、その手段として選んだのがコレ!


[第40回]


●Enumeration はじめから終わりまでの記録(8)GET_DESCRIPTOR(CONFIGURATION)

前回までのところで、ホストから再度出されたGET_DESCRIPTOR(DEVICE)リクエストに応えてPICWRITERがDEVICE DESCRIPTORを送出したところまでを説明しました。
今回はその後の送受信についての説明です。
今までの説明と同様に、少しリストが重なりますが、前回までにお見せしたリストの最後のところから後ろのリストをお見せします。

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 

PICWRITERからDEVICE DESCRIPTORが送出されてホストがそれにDATA1で応えたあと、ホストからはGET_DESCRIPTOR(CONFIGURATION)リクエストが出されます。
80 06 00 02 00 00 09 00 です。

最初の 80 06 はGET DESCRIPTORです。
次の 00 02 はその要求がCONFIGURATION DESCRIPTORを要求していることを示しています。
コード 02はCONFIGURATION DESCRIPTORを示していて、00 はINDEXです(この場合には00になります)。
次の 00 00 はリクエストによって意味が異なりますがこの場合には 00 00 です。
最後の 09 00 は要求しているDESCRIPTORの長さ(バイト数)が9バイトであることを示しています。

ホストから送出されたGET DESCRIPTOR(CONFIGURATION)リクエストに対して、端末は要求に応えてCONFIGURATION DESCRIPTORを送ります。
09 02 29 00 01 01 02 80 です。

ディスクリプタの最初の1バイトはそのディスクリプタの長さを指定します。
ここでは09ですから9バイトであることを示しています。
ディスクリプタの2バイト目は、そのディスクリプタの種類を示しています。
このディスクリプタがホストから要求されたCONFIGURATION DESCRIPTOR(コード02)であることを示しています。
次の 29 00 はCONFIGURATION,INTERFACE,ENDPOINTの各DESCRIPTORを合計した全バイト数です。
29H=41ですから全体では41バイトあることを示しています。
次の1バイトはINTERFACE DESCRIPTORの個数(このリストでは01)です。
その次の1バイトは複数のCONFIGRATION DESCRIPTORがあるときにその番号(このリストでは01)です。
しかし複数のCONFIGURATION DESCRIPTORってなんじゃいな?という疑問があります。
よくわかりませぬ。
次の1バイトはCONFIGURATION DESCRIPTORのSTRING DESCTIPTOR のINDEX(このリストでは02)です。
そもそもCONFIGURATION DESCRIPTORのSTRING DESCTIPTOR って何なんでしょう。
これもよくわかりませぬ。
8バイト目はビット7〜5までに意味があります。ビット4〜0はリザーブされています(全ビット:0)。
このリストでは80ですから、ビット7=1でそれ以外は0です。
ビット7=1はUSBバスラインから+5V電源を取ること(バスパワー)を指定しています。
ビット6は自己電源の指定です。
ビット5はリモートウェイクアップの指定です。

CONFIGURATION DESCRIPTORは9バイトですから、最後の1バイトは2回目の送信データになります。
上のリストでは下から4行目の先頭にある 32 です。
この1バイトはバスパワーを使う場合の最大消費電流です。
2mA単位で指定します。
このリストでは32Hですから500mAということになります。
これはUSB2.0規格での最大値になります。

この最後の1バイトの後ろの2バイトは前回説明しましたDEVICE DESCRIPTORの最後の2バイトの後ろと同じで、
CRC16(巡回冗長検査)です。
CRC16の2バイトの次には、前回と同じでプログラムでは検出できなかった何かがかくれているようです。
そこで前回同様手作業で解読をしてみました。
その結果はこれも前回と同じで、SYNCに続いてACKが出現しました。

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

これで前回と同様、情報が完全につながりました。
ホストはPICWRITERから送られたCONFIGURATION DESCRIPTORの最後の1バイト(とCRC16)を受け取ると、それにACKを返したあと、DATA1を送出してCONFIGURATION DESCRIPTORの受信を完了しました。

ちょっとわかりにくいかも知れませんが、上で説明しましたようにCONFIGURATION DESCRIPTORは9バイトですが、本当はこれに続いてINTERFACE DESCRIPTOR、ENDPOINT DESCRIPTORを送出することになっています。
CONFIGURATION DESCRIPTORを含めた総バイト数は29H(41バイト)である、とCONFIGURAION DESCRIPTORの3、4バイト目に記述しています。
しかしホストから出されたGET DESCRIPTOR(CONFIGURATION)リクエストで要求しているバイト数は9バイトなので、PICWRITERはCONFIGURATION DESCRIPTORの9バイトのみを送出し、ホストもその直後にデータ受信完了のマークとしてDATA1を送っています。
実はGET DESCRIPTOR(CONFIGURATION)リクエストはこれで終わりではなくて、この後のところでも出されています(次回以降で説明の予定)。
そういうところがENUMERATION手続きのややこしいところで、したがってそれに応えるためのプログラムも複雑にならざるを得ないのです。

CPLD+SIMMを使ってUSBプロトコルの解析を![第40回]
2014.4.10upload

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