2014.6.10

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

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


[第64回]


●Enumeration はじめから終わりまでの記録(17)4度目のGET_DESCRIPTOR(CONFIGURATION)

前回からの続きです。
前回はなんと4回目のGET DESCRIPTOR(STRING)の出現に、もう言葉もありません、と書きました。
一体どうなっているのでしょうか。
全くの謎なのでありますが、ともかく私といたしましては、こんなわけのわからないふるまいのもとになりますSTRING DESCRIPTORなぞ金輪際使う気はありません。
STRING DESCRIPTORは記述しなくてもよいことになっているようですし、実用上も記述する必要は全くありません。

さて。前回のリストの続きです。

0252903 SOF FNO=0B3
0252977 SETUP ADRS=04 ENDP=00 
        DATA0  80 06 00 01 00 00 12 00   GET_DESCRIPTOR DEVICE
        ACK 
0252978 IN ADRS=04 ENDP=00 
        NAK 
0252980 IN ADRS=04 ENDP=00 
        NAK 
0252980 IN ADRS=04 ENDP=00 
0252982 IN ADRS=04 ENDP=00 
        DATA1  12 01 00 02 00 00 00 08   
        ACK 
0252984 IN ADRS=04 ENDP=00 
        NAK 
0252985 IN ADRS=04 ENDP=00 
        NAK 
0252986 IN ADRS=04 ENDP=00 
        DATA0  D8 04 33 00 02 00 01 02   
        ACK 
0252987 IN ADRS=04 ENDP=00 
0252988 IN ADRS=04 ENDP=00 
0252989 ACK 
0252990 OUT ADRS=04 ENDP=00 
        DATA1  
        ACK 
0252997 SOF FNO=0B2
0252997 PRE 
0253013 SETUP ADRS=04 ENDP=00 
        DATA0  80 06 00 02 00 00 09 00   GET_DESCRIPTOR CONFIG
        ACK 
0253015 IN ADRS=04 ENDP=00 
        NAK 
0253016 IN ADRS=04 ENDP=00 
        NAK 
0253017 IN ADRS=04 ENDP=00 
        NAK 
0253018 IN ADRS=04 ENDP=00 
        NAK 
0253020 IN ADRS=04 ENDP=00 
        DATA1  09 02 29 00 01 01 02 80   
        ACK 
0253021 NAK 
0253022 IN ADRS=04 ENDP=00 
        DATA0  32 C1 6A 3B A0 F4 1E   
0253023 OUT ADRS=04 ENDP=00 
        DATA1  
        ACK 
0253045 SETUP ADRS=04 ENDP=00 
        DATA0  80 06 00 02 00 00 29 00   GET_DESCRIPTOR CONFIG
        ACK 
0253046 IN ADRS=04 ENDP=00 
        NAK 
0253047 IN ADRS=04 ENDP=00 
        NAK 
0253048 IN ADRS=04 ENDP=00 
        NAK 
0253050 IN ADRS=04 ENDP=00 
        DATA1  09 02 29 00 01 01 02 80   
        ACK 
0253051 IN ADRS=04 ENDP=00 
        NAK 
0253053 IN ADRS=04 ENDP=00 
        NAK 
0253054 IN ADRS=04 ENDP=00 
        NAK 
0253056 IN ADRS=04 ENDP=00 
        DATA0  32 09 04 00 00 02 03 00   
0253057 ACK 
0253057 IN ADRS=04 ENDP=00 
        NAK 
0253059 IN ADRS=04 ENDP=00 
        NAK 
0253060 IN ADRS=04 ENDP=00 
        NAK 
0253061 IN ADRS=04 ENDP=00 
        DATA1  
        ? [00000001]
        ? [10000110]
0253062 IN ADRS=04 ENDP=00 
        NAK 
0253064 IN ADRS=04 ENDP=00 
        NAK 
0253065 IN ADRS=04 ENDP=00 
        NAK 
0253067 IN ADRS=04 ENDP=00 
        DATA0  22 1D 00 07 05 81 03 40   
        ACK 
0253068 IN ADRS=04 ENDP=00 
        NAK 
0253069 IN ADRS=04 ENDP=00 
        NAK 
0253070 IN ADRS=04 ENDP=00 
        NAK 
0253072 IN ADRS=04 ENDP=00 
        DATA1  00 01 07 05 01 03 40 00   
        ACK 
0253074 IN ADRS=04 ENDP=00 
        NAK 
0253075 IN ADRS=04 ENDP=00 
        DATA0  01 81 7F 3A A0 F4 7E 00   
0253077 OUT ADRS=04 ENDP=00 
        DATA1  
        ACK 

やっとSTRING DESCRIPTORから抜け出せたようです。
おやおや。
今度はDEVICE DESCRIPTORの要求です。
GET DESCRIPTOR(DEVICE)は[第38回]で説明しました。
USB接続を開始したとき最初にホストから出されるのが、このGET DESCRIPTOR(DEVICE)で、その後アドレスが与えられて再びGET DESCRIPTOR(DEVICE)が出されます。
そのときその要求に応えてしっかりDEVICE DESCRIPTORを送りましたのに、STRING DESCRIPTORと同じく、またもや同じGET DESCRIPTOR(DEVICE)です。

うむむ。
USBのENUMERATIONというのはちょっとしつこいといいますか、何かおかしいのと違いますかあ。
ぼやいてみたってはじまりません。
要求されたら何回でもそれに応えるしかありません。
で、応えますと。
今度はGET DESCRIPTOR(CONFIGURATION)です。
GET DESCRIPTOR(CONFIGURATION)は[第40回]で説明しました。
そのときと全く同じことの繰り返しです。

あ。
いえ。
全く同じではないようです。
[第40回]ではGET DESCRIPTOR(CONFIGURATION)で9バイトのみの要求に対して先頭の9バイトを送ると、次はSTRING DESCRIPTORの要求が出されました([第43回])。

しかし今回は続いてまた同じGET DESCRIPTOR(CONFIGURATION)が出されています。
よく見ますと先のGET DESCRIPTOR(CONFIGURATION)では9バイトの要求だったのですが、今度は41バイト(29H)の要求です。
これは先のGET DESCRIPTOR(CONFIGURATION)に応えて送った
09 02 29 00 01 01 02 80
の3バイト、4バイト目でCONFIGURATION DESCRIPTORの全体の長さか0029H(41バイト)だと記述したことに対して出された要求のようです。

それに応えてPICWRITERからは、今度はCONFIGURATION DESCRIPTORの全部が送出されています。
全データは41バイトですから8ビットを6回送出しなければならないはずですが、リストでは5回しか見えません。
どうやら中ほどに少し乱れが見えますからそこに1回のデータがあって、それが自作アナライザではうまくキャッチできなかったようです。
ま。しかし。
そのあたりはそういうことにしておきましょう。
余り繰り返し同じ要求が出されるものですから、いささか疲れてしまいました。
次にいきましょう。

[14.6.11追記]
昨晩はこの記事を書きながら、「はて、GET DESCRIPTOR(CONFIGURATION)は、まだほかにも出されていたのじゃなかったかなあ?」とちょいと疑問を感じたのですが、もう眠かったのでよく確認しないで書いてしまいました。
やっぱりしっかりウラをとらないで書いたりしますと間違ったことを書いてしまいます。
GET DESCRIPTOR(CONFIGURATION)は上に書きました2回目の9バイトの要求の後、一旦はSTRING DESCRIPTORの要求が出されたあと、今度はバイト数を指定しないで3回目が出されておりました([第45回][第46回])。
つうことは、このときCONFIGURATION DESCRIPTORの全てを送っておりますから、もうそれで完了していてもよさそうなものだと思います。
それなのにまたもや同じ要求が重ねて出されていることになります。
むむ。
STRING DESCRIPTORだけではなくて、ここでもしつこいことをやっているのですねえ。
ま。
少しずつは進んでいるようでありまして、この前の要求ではバイト数を指定しないでFFHとしての要求だったのですが(トータルが41バイトだということはその前のときに送っていますから、本当はもうそこで29Hを指定してもよさそうなものだと思いますけれど)、今回はやっとバイト数を41バイト(29H)と指定して要求が出されています。
いやあ。
ENUMERATIONは本当にしつこい!

CPLD+SIMMを使ってUSBプロトコルの解析を![第64回]
2014.6.10upload
2014.6.11追記

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