２０１４．２．２４

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

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


［第２１回］


●違いが分かりましたでしょうか？

前回は私が所有するＷｉｎｄｏｗｓ７（Ｈｏｍｅｐｒｅｍｉｕｍ、３２ｂｉｔ）に秋月のＰＩＣＷＲＩＴＥＲを接続したときの記録と、吉崎様からお借りしたＷｉｎｄｏｗｓＸＰパソコンに、秋月のＰＩＣＷＲＩＴＥＲを接続して得られた記録とをお見せして、両者の「驚くべき違い」が分かりますでしょうか？と書いたところで終わってしまいました。
もう一度下にその違いがよくわかる部分を再掲してお見せします。
こちらが私のＷｉｎｄｏｗｓ７パソコンです。

0087428 SOF FNO=46F [101001011111011000110110]
0087523 SOF FNO=470 [101001010000111000100001]
        SETUP ADRS=01 ENDP=00  [101101001000000000010111]
        DATA0 
        80 06 00 01 00 00 12 00   GET_DESCRIPTOR DEVICE
        ACK 
0087617 SOF FNO=471 [101001011000111000111110]
        IN ADRS=01 ENDP=00  [1001011010000000000]
        DATA1 
        12 01 00 02 00 00 00 08   
        ACK 
0087711 SOF FNO=472 [101001010100111000111100]
        IN ADRS=01 ENDP=00  [1001011010000000000]
        DATA0 
        D8 04 33 00 02 00 01 02   
        ACK 
0087804 SOF FNO=473 [101001011100111000100011]
        IN ADRS=01 ENDP=00  [1001011010000000000]
        DATA1 
        03 02 7F 7E FB 81 D2 0B   
0087898 SOF FNO=474 [101001010010111000111101]
        OUT ADRS=01 ENDP=00  [1000011110000000000]
        DATA1 
        00 00 FB 80 D2 FB 4B 2F   
0087991 SOF FNO=475 [101001011010111000100010]
0088086 SOF FNO=476 [101001010110111000100000]
        SETUP ADRS=01 ENDP=00  [101101001000000000010111]
        DATA0 
        80 06 00 02 00 00 FF 00   GET_DESCRIPTOR CONFIG
        ACK 
0088180 SOF FNO=477 [101001011110111000111111]
        IN ADRS=01 ENDP=00  [1001011010000000000]
        DATA1 
        09 02 29 00 01 01 02 80   
        ACK 
0088274 SOF FNO=478 [101001010001111000101111]
        IN ADRS=01 ENDP=00  [1001011010000000000]
        DATA0 
        32 09 04 00 00 02 03 00   
        ACK 
0088367 SOF FNO=479 [101001011001111000110000]
        IN ADRS=01 ENDP=00  [1001011010000000000]


こちらが吉崎様からお借りしたＷｉｎｄｏｗｓＸＰパソコンです。

0025584 SOF FNO=650 [101001010000101001111010]
0025584 PRE 
0025678 SOF FNO=651 [101101011000101001100101]
0025758 DATA0 
        80 06 00 01 00 00 12 00   GET_DESCRIPTOR DEVICE
        ACK 
0025760 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025761 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025763 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025765 IN ADRS=04 ENDP=00  [1001011000100000000]
        DATA1 
        12 01 00 02 00 00 00 08   
        ACK 
0025772 SOF FNO=652 [101001010100101001100111]
0025773 PRE 
0025777 IN ADRS=04 ENDP=00  [1001011000100000000]
        DATA0 
        D8 04 33 00 02 00 01 02   
        ACK 
0025778 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025779 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025779 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025781 IN ADRS=04 ENDP=00  [1001011000100000000]
        DATA1 
        03 02 7F 7E 1B 50 7A 7F   
0025783 OUT ADRS=04 ENDP=00  [1000011100100000000]
0025807 SETUP ADRS=04 ENDP=00  [101101000010000000010100]
        DATA0 
        80 06 00 02 00 00 09 00   GET_DESCRIPTOR CONFIG
        ACK 
0025809 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025810 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025811 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025813 IN ADRS=04 ENDP=00  [1001011000100000000]
        DATA1 
        09 02 29 00 01 01 02 80   
        ACK 
0025814 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025815 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025817 IN ADRS=04 ENDP=00  [1001011000100000000]
        DATA0 
        32 C1 6A 1B 50 7A 7F C0   
0025818 OUT ADRS=04 ENDP=00  [1000011100100000000]
0025856 SETUP ADRS=04 ENDP=00  [101101000010000000010100]
        DATA0 
        80 06 00 03 00 00 FF 00   GET_DESCRIPTOR 
        ACK 
0025857 ACK 
0025858 IN ADRS=04 ENDP=00  [1001011000100000000]
        NAK 
0025866 SOF FNO=653 [101001011100101001111000]

違いが分かりましたでしょうか？

●これはスピード違反です！

私自身はその違いに全く気がつきませんでした。
毎日何回も何回もデータを取り直して、そしてそれこそ穴があくほど見比べていたのですけれど、気が付きませんでした。
いくら眺めていても埒があきませんので、攻める方向を変えて、ＰＩＣの中の動きも同時進行で見えるようにツールを組み立て直して、ＰＩＣの中と外の動きを比べてみて、やっと気が付きました。

吉崎様からお借りしたパソコンのＵＳＢ信号は余りに速過ぎたのです。
いえ。クロックのことではありません。
どちらも１２ＭＨｚで、そこに違いはありません。
問題はホストから送出されるコマンドのタイミングの速さの違いにありました。

上の２つのリストの違いはそこにありました。
もう一度最初のリストを見てください。
ＦＮＯ（フレームナンバー）が並んでいます。
その間隔は１ｍｓです。
最初のリストはＳＥＴＵＰコマンドやＩＮパケットが１フレームに１回の割合で出されています。
そもそものＰＩＣＵＳＢプログラムの作成を開始するにあたって参考にした「トランジスタ技術」２０００年６月号の参考例（２０２ページ）でも全く同じ記載でしたので、そういうものだとすっかり信じ込んでしまいました。

ところが吉崎様からお借りしたＷｉｎｄｏｗｓＸＰパソコンでのリストを見てみますと、そこではとんでもないことがおきています。
このリストはＦＮＯ＝６５１と６５２のわずか２フレームの間でのコマンド、データのやり取りであることに注目してください。

なんと１つのフレームの中で矢継ぎ早にＳＥＴＵＰコマンドとＩＮパケットが送出されていたのです。

たとえば００２５６７８行のＳＯＦ　ＦＮＯ＝６５１で始まったフレームでは、ＤＡＴＡ０でコマンドが送出されたあと、ＩＮパケットが連続して４回も送出されています。
ＰＩＣＷＲＩＴＥＲはとてもそれには応答できないので、連続してＮＡＫを返しています。

ところが私のＰＩＣプログラムはといいますと、何しろ１ｍｓに１回応答すればよいと信じてしまっていたものですから、間に合わなかったらＮＡＫを返す、というようには作っていなかったのでした。
なにしろ１ｍｓに１回ですから、間に合わないはずがないと思い込んでいました。
当然ホストからの要求にまともに応えられませんので、「不明なデバイス」にされてしまっていたのだと思います。

速いと書きましたが、それは一体どの程度の速さなのか？
上のリストでは今ひとつピンとこないかも知れません。
そこで上のリストのさらに一部分をもとの１６進数ダンプデータで説明することにいたします。
下は上のリストの中ほど、２５８０７行から２５８０９行のあたりの１６進数データと、その部分を解読したものです。

D6PX_4.TXT
25806 FF FF FF FF FF 03 B6 10 A0 28 E0 30 A0 01 80 00 
25807 00 40 02 80 2B C1 3E A0 F4 FE FF FF FF FF FF FF 
25808 FF FF FF FF FF FF FF FF FF FF FF FF FF 7F C0 34 
25809 02 14 7D 40 AD FD FF FF FF FF FF FF FF FF FF FF 

03       B6       10       A0       28       E0       30       A0       01 
11000000 01101101 00001000 00000101 00010100 00000111 00001100 00000101 10000000
          |        |       |   |     |            |        |        |        |
  SYNC     SETUP    ADRS=4  EP=0 CRC5     SYNC     DATA0    80       06

80       00       00       40       02       80       2B       C1       3E 
00000001 00000000 00000000 00000010 01000000 00000001 11010100 10000011 01111100
     |        |        |        |        |        |        |        |
00    02       00       00       09       00       CRC16

A0       F4       FE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
00000101 00101111 
     |        |
SYNC  ACK

7F       C0       34       02       14       7D       40       AD       FD 
11111110 00000011 00101100 01000000 00101000 10111110 00000010 10110101 10111111
               |        |       |    |    |                 |        |
       SYNC     IN       ADRS=4  EP=0 CRC5           SYNC    NAK

ホストからＤＡＴＡ０に続いて８バイトのコマンドが出力されています。
そのあと少しの間無信号（ＦＦ）が続いたあと、ＩＮパケットが送出されています。
ＵＳＢ機器は本来は８バイトのコマンドを受け取ったあと、それを解読して、そのコマンドに合ったデータを次のＩＮパケットに合わせて送出することが要求されています。
それでは上の場合、コマンドデータの送出が終わってから、次にＩＮパケットが出力されるまでの時間はどれほどでしょうか。
コマンドをＰＩＣ１８Ｆ１４Ｋ５０のＳＩＥ（Ｓｅｒｉａｌ　Ｉｎｔｅｒｆａｃｅ　Ｅｎｇｉｎｅ）が受信してそれがユーザープログラムに渡せるようになるタイミングはおそらくＣＲＣ１６の受信が終わってからだと思いますから、そこからＩＮパケットに続いてＣＲＣ５が受信されるまでの間は２８バイトデータほどです。
ＵＳＢのクロックは１２ＭＨｚで２８×８＝２２４ｂｉｔですから、２２４／１２≒１８．７μｓです。
たったそれだけの時間でコマンドを解読してデータを送り返さなければなりません。
さすがにそれはクロック４８ＭＨｚで動くＰＩＣ１８Ｆ１４Ｋ５０でもいかにもきびしい要求です。
さきほどのＷｉｎｄｏｗｓＸＰに接続したＰＩＣＷＲＩＴＥＲでも３回ＮＡＫを返したあとでやっとデータを送出しています。

この速さは一体どういうことなのでしょう。
吉崎様からメールをいただいてやっと得心いたしました。

吉崎様からお借りしたパソコンはＵＳＢ３．０という規格のインターフェイスを搭載しているということを教えていただきました。
私の所有するパソコンははっきり確認したわけではありませんが、おそらくＵＳＢ２．０規格なのでありましょう。
上の２つのデータから類推しますと、おそらくＵＳＢ２．０規格ではＥｎｕｍｅｒａｔｉｏｎのコマンドやデータの送受信は最速でも１フレームに１回の頻度で行なわれると思われるのに対して、ＵＳＢ３．０では１つのフレームで複数回の送受信が行なわれるようです。

それで私のところではＷｉｎｄｏｗｓ７でも認識されるのに、お客様によってはＷｉｎｄｏｗｓＸＰでも認識されないというおかしな現象がおきていたのでした。
やっと原因らしきものがわかってきましたので、さっそくそれに合わせてＰＩＣプログラムの改良に取り掛かりました。

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

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