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


［第４８回］


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

このところいつも同じ書き出しになってしまいます。
またまた間が空いてしまいました。
気にはしているのです。
今日はせめて少しだけでも書かなければ。
そう思いつつホームページの更新にまで手が回らずに１日が終わってしまいます。
もうしばらくこの状態が続きそうです。

前回はホストから出されたＧＥＴ＿ＤＥＳＣＲＩＰＴＯＲ（ＳＴＲＩＮＧ）リクエストと、それに応えてＰＩＣＷＲＩＴＥＲから出されたＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲ（コード０３）のインデックス０２（ＰＲＯＤＵＣＴ）について説明をしました。
最初にホストから出されたＧＥＴ　ＤＥＳＣＲＩＰＴＯＲ（ＳＴＲＩＮＧ）リクエスト　０８　０６　００　０３　００　００　ＦＦ　００　はＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲのインデックス０を要求するもので、［第４２回］での説明と同じものがまた出されています。
「同じことをどうして重ねて要求するのか理解に苦しみます。」
と前回書きました。

ところがそんなもんじゃないのですよねえ。これが。
下が前回の続きなのですが…。

0026128 OUT ADRS=04 ENDP=00 DATA1 ACK 0026159 SETUP ADRS=04 ENDP=00 DATA0 80 06 00 03 00 00 FF 00 GET_DESCRIPTOR ACK 0026160 NAK 0026162 NAK 0026163 IN ADRS=04 ENDP=00 DATA1 04 03 09 04 09 78 3B A0 0026165 OUT ADRS=04 ENDP=00 DATA1 ACK 0026181 SOF FNO=740 DATA1 0026181 ? [01110111] 0026194 SETUP ADRS=04 ENDP=00 DATA0 80 06 02 03 09 04 FF 00 GET_DESCRIPTOR ACK 0026195 IN ADRS=04 ENDP=00 NAK 0026196 IN ADRS=04 ENDP=00 NAK 0026197 IN ADRS=04 ENDP=00 NAK 0026200 IN ADRS=04 ENDP=00 DATA1 48 03 50 00 49 00 43 00 ACK 0026201 IN ADRS=04 ENDP=00 NAK 0026202 IN ADRS=04 ENDP=00 NAK 0026203 IN ADRS=04 ENDP=00 NAK 0026205 IN ADRS=04 ENDP=00 DATA0 6B 00 69 00 74 00 20 00 ACK 0026205 IN ADRS=04 ENDP=00 NAK 0026206 IN ADRS=04 ENDP=00 NAK 0026207 IN ADRS=04 ENDP=00 NAK 0026208 IN ADRS=04 ENDP=00 NAK 0026208 IN ADRS=04 ENDP=00 NAK 0026210 IN ADRS=04 ENDP=00 DATA1 32 00 20 00 4D 00 69 00 ACK 0026211 IN ADRS=04 ENDP=00 NAK 0026211 IN ADRS=04 ENDP=00 0026212 IN ADRS=04 ENDP=00 NAK 0026213 IN ADRS=04 ENDP=00 NAK 0026215 IN ADRS=04 ENDP=00 DATA0 63 00 72 00 6F 00 63 00 ACK 0026215 IN ADRS=04 ENDP=00 NAK 0026216 IN ADRS=04 ENDP=00 NAK 0026217 IN ADRS=04 ENDP=00 NAK 0026218 IN ADRS=04 ENDP=00 NAK 0026220 IN ADRS=04 ENDP=00 DATA1 6F 00 6E 00 74 00 72 00 ? [01111101] 0026220 IN ADRS=04 ENDP=00 NAK 0026221 NAK 0026222 IN ADRS=04 ENDP=00 NAK 0026223 IN ADRS=04 ENDP=00 NAK 0026224 IN ADRS=04 ENDP=00 DATA0 6F 00 6C 00 6C 00 65 00 ACK 0026225 IN ADRS=04 ENDP=00 NAK 0026226 IN ADRS=04 ENDP=00 NAK 0026226 IN ADRS=04 ENDP=00 NAK 0026227 IN ADRS=04 ENDP=00 NAK 0026229 IN ADRS=04 ENDP=00 DATA1 72 00 20 00 50 00 72 00 ACK 0026230 IN ADRS=04 ENDP=00 NAK 0026231 IN ADRS=04 ENDP=00 NAK 0026231 IN ADRS=04 ENDP=00 NAK 0026232 IN ADRS=04 ENDP=00 NAK 0026234 IN ADRS=04 ENDP=00 DATA0 6F 00 67 00 72 00 61 00 ACK 0026234 IN ADRS=04 ENDP=00 NAK 0026235 IN ADRS=04 ENDP=00 NAK 0026236 IN ADRS=04 ENDP=00 0026237 IN ADRS=04 ENDP=00 NAK 0026238 IN ADRS=04 ENDP=00 DATA1 6D 00 6D 00 65 00 72 00 ACK 0026239 IN ADRS=04 ENDP=00 NAK 0026240 IN ADRS=04 ENDP=06 NAK 0026241 SOF FNO=407 ? [10111000] ACK 0026242 OUT ADRS=04 ENDP=00 DATA1 ACK

ちょっと待ってくださいよお。
と思わず言いたくなってしまいます。
これ。
前回と全く同じリストじゃありませんか（そのことがよくわかるように前回のリストの終わりの３行を今回のリストの先頭に残しました）。

ええ。
ちゃんとホストからの要求に応えてＳＴＲＩＮＧ　ＤＥＳＣＲＩＰＴＯＲ（ＰＲＯＤＵＣＴ）を返したのですけれど、どういうわけかもう一度同じことが要求されています。
うーん。
先のデータにどこかおかしいところでもあったのでしょうかねえ。
ちょいと理解できかねますです。

あ。
今回は最後のところでちょっとデータが乱れているようで解読に失敗しています。
前回と同じやり取りだとすると、ここは最後にデータ無しのＤＡＴＡ０を送出しているところなのですが…。

多分そうだろうとは思いましたが念のためまた紙とエンピツで解読してみました。

26240 60 1A C1 7A 3E A0 D6 FE FF FF FF FF 1F 30 FF 8D `..z>........0.. 26241 00 45 0F 38 0C 00 B0 03 4A EF FF FF FF FF FF FF .E.8....J....... 1F 30 FF 8D 00 45 0F 38 0C 00 B0 03 4A EF FF 11111000 00001100 11111111 10110001 00000000 10100010 11110000 00011100 00110000 00000000 00001101 11000000 01010010 11110111 | | | | | | | | | SYNC IN? SYNC ? SYNC DATA0 CRC16? SYNC ACK

うむむ。
確かに少しデータが乱れていますねえ。
ここは本当はＩＮパケットのはずなのですが、正しくは読み取れません。
あ。
でも、その後の、値なしのＤＡＴＡ０とＡＣＫは解読できました。
やはりそういうことのようです。

ＵＳＢ通信の動作を確認するために何回も何回もそれこそいやになるくらい繰り返してデータをとって確認したのですが、今回説明しましたようにどういうわけか、繰り返し同じことを要求される場合がよくあります。
なぜだかよくわかりません。
データがうまく読み取れないのかとも考えたのですが、やっぱりそれはちょいとおかしいでしょう。
こんなところで誤読してしまうようなら危なくてデータの送受信などまともに行なえません。
そうなると何か別の理由で同じことが繰り返し要求されるのだろうということになりますが、その理由は皆目見当もつきません。
やっぱり、なんだかなあ、と思うしかないようです。

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

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