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


［第２５回］


●ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲ

ＵＳＢ機器をパソコンに接続すると、最初にＥｎｕｍｅｒａｔｉｏｎという手続きが開始されます。
これはなかなかに面倒でわかりにくい手続きです。
ネット上でもそれこそいやになってしまうくらいあれこれ調べましたし、もちろん「トランジスタ技術」の過去記事も繰り返し読みました。
それでもいまひとつはっきりしないところがありました。
自分ではわかったつもりでいても、やはり理解しきれていないところが残っていたようです。

すでに書きましたように、唐突にＣＰＬＤ＋ＳＩＭＭなんてものを持ち出してＵＳＢ信号の解析をやりはじめましたのは、ＮＤ８０Ｚ�V（ＮＤ８０Ｚ３．５）をご購入いただいた方のうち何人かの方から「ＵＳＢで接続しようとすると不明なデバイスと表示されて接続できません」というメールをいただいたことに端を発しています。
しかし私の所有するＷｉｎｄｏｗｓ９８からＷｉｎｄｏｗｓ７までのパソコンの全てでND80Z�V（ＮＤ８０Ｚ３．５）をＵＳＢ接続すると正しく認識されてしまうために、これまでどうすることもできませんでした。
たまたま�葛Z術少年出版の吉崎様がお持ちのパソコンでも同様のことが発生したとのメールをいただきましたので、それをお借りして徹底的に調べてみることにしました。

いろいろ調べていくうちに、どうやらそれがＵＳＢ３．０という規格のせいであるらしいということがわかってきました。
ＮＤ８０Ｚ�V（ＮＤ８０Ｚ３．５）に搭載のＰＩＣ１８Ｆ１４Ｋ５０に仕込んであるプログラムはＨＩＤデバイスというクラスのもので、ＵＳＢ２．０（厳密に言えばＵＳＢ１．１）規格のものです。
ＵＳＢ３．０は２．０も１．１も接続できるのですが、どうやら完全に互換ではなくて、それなりに機能アップされたもののようです。
調べてみてわかってきたことのひとつがアクセスタイムがやたら速いということでした。
私はそんな規格は全く知らなかったものですから、当然そのような速度に応えるプログラムにはなっていませんでした。
そのために吉崎様からお借りしたパソコンではＵＳＢ接続でこけてしまっていたのでした。
以上の経緯については、今までの回で説明をいたしました。

実はそのほかにも副産物といいますか、当初どうにも信じられなかったちょっと納得できかねるルールがあることにも気が付きました。
それが今回のテーマのＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲについての扱いです。

ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲは装置のメーカー名やデバイス名などを文字情報としてホストに伝えるためのディスクリプタです。
このＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲは必須ではなくて省略可能です。
余計なものをつければそれだけ面倒なことになる度合いも増えますので、ND80Z�V（ＮＤ８０Ｚ３．５）に搭載のＰＩＣ１８Ｆ１４Ｋ５０のプログラムではＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲは省略していたのですが、ＵＳＢ接続で認識できないという問題を解決していくなかで、ひょっとしたらそのこと（ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲを省略していること）が認識されない要因かとも考えて、それも追加してテストをしていくなかでＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲについてのホストからのちょいと不思議な要求がだんだんと明らかになってきました。

このように書いていましても、実は今でも内心「ほんまかいな」とまだいささか腑に落ちていないところがあります。
上に書きましたように、ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲは省略可能ですので、本当はこんなことは深く追求しなくてもよいことなのかもしれませんが、納得できないままにしておくのも面白くありませんし、この機会に将来のためにできれば追求してはっきりさせておこうと思ったのです。

ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲは英語以外の言語にも対応するためだと思いますが、１６ビットで１文字を示すルールになっています。
これは実際にプログラムでアルファベットコード（ＡＳＣＩＩコード）を使って記述する場合にはなかなか手間がかかるルールです。
とりあえず以上のことを予備知識としていただいて、なにはともあれ実際のデータのやりとりの様子を見ていただくことにいたしましょう。

下は吉崎様からお借りしたＷｉｎｄｏｗｓＸＰパソコン（ＵＳＢ３．０）に秋月のＰＩＣＷＲＩＴＥＲを接続したときのＵＳＢ信号をＣＰＬＤ＋ＳＩＭＭ回路で記録して、そのデータを自作ソフトで解読したものの一部です。
解析作業を繰り返し行なっていくうちに、ＣＰＬＤ＋ＳＩＭＭに仕込むＶＨＤＬプログラムも、それから解読のための８０８６プログラムもだんだんと精度のよいものになってきました。
下のリストなどは、はじめのころに見ていただいておりましたものに比べますと、ちょいと自画自賛でありますが、なかなか見事なできばえだと思います。
ここまでできればほとんど完璧といってもよろしいのではありませんでしょうか。

(D6PX6CK.TXT) 0025900 SOF FNO=73D 0025910 SETUP ADRS=04 ENDP=00 DATA0 80 06 03 03 09 04 FF 00 GET_DESCRIPTOR ACK 0025912 IN ADRS=04 ENDP=00 NAK 0025913 IN ADRS=04 ENDP=00 NAK 0025914 IN ADRS=04 ENDP=00 NAK 0025916 IN ADRS=04 ENDP=00 DATA1 10 03 4F 00 6C 00 48 00 ACK 0025918 IN ADRS=04 ENDP=00 NAK 0025918 IN ADRS=04 ENDP=00 NAK 0025919 IN ADRS=04 ENDP=00 NAK 0025920 IN ADRS=04 ENDP=00 NAK 0025922 IN ADRS=04 ENDP=00 DATA0 6F 00 73 00 73 00 00 00 ACK 0025922 IN ADRS=04 ENDP=00 NAK 0025924 IN ADRS=04 ENDP=00 DATA1 ACK 0025926 OUT ADRS=04 ENDP=00 DATA1 ACK 0025960 SETUP ADRS=04 ENDP=00 DATA0 80 06 00 02 00 00 FF 00 GET_DESCRIPTOR CONFIG ACK

このリストでは、ホストから送出されたＧＥＴ　ＤＥＳＣＲＩＰＴＯＲコマンドと、それに応えてＰＩＣＷＲＩＴＥＲからＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲが送出されたところが記録されています。

ここで簡単にコマンドについて説明をしておきましょう。
Ｅｎｕｍｅｒａｔｉｏｎ手続きでは、ホストから送られるコマンドも、装置から返されるデータもともに一度に送るのは８バイト以内というルールがあります。
リストの最初にある　８０　０６　０３　０３　０９　０４　ＦＦ　００　がホストから送られたコマンドです。
最初の２バイト　８０　０６　がディスクリプタ送信要求です。
次の　０３　０３　は、前の０３はＩＮＤＥＸで、後ろの０３がＤＥＳＣＲＩＰＴＯＲの種類（０３はＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲ）を示しています。
ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲはＩＮＤＥＸ０（基本情報）とメーカー名、製品名、製品番号（シリアルナンバー）に分けてそれぞれを区別するＩＮＤＥＸをつけて示します。
それぞれのＩＮＤＥＸをどういう番号にするかは、最初に送るＤＥＶＩＣＥ　ＤＥＳＣＲＩＰＴＯＲに記述します。
ＰＩＣＷＲＩＴＥＲの場合ＩＮＤＥＸ＝０３はシリアルナンバーのようです。
次の　０９　０４　はＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲを記述する言語の指定です。
０４０９は英語（アルファベット）で表記することを示しています。
Ｅｎｕｍｅｒａｔｉｏｎでは１６ビットのデータは最初に下位バイト、次に上位バイトの順に並べます。

最後の　ＦＦ　００　は送信すべきＤＥＳＣＲＩＰＴＯＲの長さ（バイト数）の指定です。
ここでの長さの指定は１６ビットですが、実際にディスクリプタを送信するときにはその先頭でもディスクリプタの長さを指定します。
ところがディスクリプタの先頭に置く長さ指定のためのエリアは１バイトという決まりになっていますので、実際には最長でも２５５バイト（ＦＦＨ）の長さしか記述ことはできません。
ですからここが００ＦＦであるのは、ホストからは長さを指定していないことを示しています。

ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲ送信要求コマンドが送出されて、ＰＩＣＷＲＩＴＥＲがそれを受け取ってＡＣＫを返すとホストからはほとんど間髪を入れずにＩＮパケットが連続して送出されています。
まるで「はよォ送らんかい。われ、なにもたもたしとんねん」とでも言われているようです。
前にもちょっと説明しましたが行の先頭に表示されている７桁の数字は、ＵＳＢデータを１６進数ダンプ表示したときの行番号に相当しています。
その１行は１６バイト（１２８ビット）のデータです。
上のリストで見ますとこのときのＩＮパケットはほとんど毎行発行されていますから、その間隔は、ＵＳＢ信号のクロックが１２ＭＨｚなので
１２８／１２≒１１μＳほどと計算されます。

その速さではさすがにＰＩＣＷＲＩＴＥＲも即答は無理のようで、準備ができるまでＮＡＫを返しています。
２５９１６行のＩＮパケットになって、やっとＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲの最初の８バイトを送っています。
この８バイトの意味ですが、先頭の１バイトはディスクリプタの長さを示しています。
１０Ｈですからこのディスクリプタ（シリアルナンバー）は全体で１６バイトであることを示しています（この数値を覚えておいてください）。
次の０３はこのディスクリプタがＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲであることを示しています。
ディスクリプタの先頭の１バイトはそのディスクリプタの長さ（バイト数）で、次の１バイトはそのディスクリプタの種別を示します。
上でも書きましたように、ＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲの種別コードは０３です。
３バイト目からはディスクリプタのデータそのものの記述が続きます。
その部分は　４Ｆ　００　６Ｃ　００　４８　００　ですから、”ＯｌＨ”です。
その次に送出された８バイトは　６Ｆ　００　７３　００　７３　００　００　００　ですから”ｏｓｓ”です。
続けると　”ＯｌＨｏｓｓ”になります。
意味不明な文字列です。
何でしょう？
ここはシリアルナンバーのはずなのですが…。

それはともかくとしまして、このリストに表示されているコマンドとデータのやり取りにはおかしいところがあるのですが、それはどこだかおわかりになりますでしょうか。
おかしいというよりも、理屈に合わないと言うべきでしょうか。

あ。
もう少し説明を加えてから考えていただいたほうがよいかもしれませんね。
コマンドやデータは送受信の途中でノイズなどの影響で落ちてしまって途中のやり取りが欠落してしまう可能性を考慮したためでしょうか、先頭にＤＡＴＡ０かＤＡＴＡ１パケットをつけて送られます。
ＤＡＴＡ０とＤＡＴＡ１は交互に送ります。
ホストから送られるコマンドはやり取りの開始ですから必ずＤＡＴＡ０です。
それに対する装置からの返答はＤＡＴＡ１から始めます。
装置からの応答が８バイト以上の場合は、８バイトごとに区切って、最初にＤＡＴＡ１、次にＤＡＴＡ０、その次はＤＡＴＡ１というように交互に送ります。

ところでこれものちほどまた説明しますが、所定のバイト数のデータをホストが受け取ると、ホストはそれを受け取ったしるしとして中身の無いＤＡＴＡ１を装置に返します（このときは装置側がＤＡＴＡ１で終わったときでも必ずＤＡＴＡ１が送出されます）。

さてそれだけのことを頭に入れていただいた上でもう一度上のリストのやり取りを見てください。
ほら。
おかしいことに気がつきませんでしょうか？

本日は時間がなくなってしまいました。
この続きは次回にいたします。

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

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