ＶＨＤＬを速習！ ＸＣ９５１４４ＸＬ＋１６ＭＢ・ＳＩＭＭを使ってＵＳＢプロトコルアナライザを作ってしまいました！
主目的は差し迫った事情からＵＳＢプロトコルの解析をすることだったのですが、その手段として選んだのがコレ！
［第５８回］
●ＰＩＣ１８Ｆ１４Ｋ５０のＲｅａｄ－ｍｏｄｉｆｙ－ｗｒｉｔｅの怪
毎度同じことを書いておりますが、またまた何日ぶりかの更新になってしまいました。
このところ㈱技術少年出版様のＬｅｇａｃｙ８０８０の仕上げ作業にかかっておりまして、そこにお得意さまからの急ぎの注文が重なってしまったものですから、ホームページの更新にまで手が回りませんでした。
それと今回のタイトル（これもしっかりテーマ違いなのですが）、このことについても書いておかなくてはと思ったのですけれど、書くからには裏づけが必要と。
やっぱりしっかりとウラを取っておきませんと誤認逮捕などで世間を騒がしてしまいますです。
しかしその裏づけのためのテストをしている時間がありません。
ということなどで、ホームページの更新ができませんでした。
やっと少し時間をみつけて、テストを行なってウラが取れたものですから、今回の記事となりました。
ウラを取る必要があるほどの「事件」とは何でありましょうか？
今回のタイトルにありますように、それはＰＩＣ１８Ｆ１４Ｋ５０で発生した奇怪な現象でありました。
それが発生しましたのは、前回まで数回にわたって書いてきました、これもテーマ違いの「Ｌｅｇａｃｙ８０８０のＣＰＵ ＲＥＳＥＴによるウォームブート対策」の作業中の出来事でした。
前回までに説明しましたような経緯で、Ｚ８Ｓ１８０のプログラムとＰＩＣ１８Ｆ１４Ｋ５０のプログラムを書き換えましたところ、どういうわけかプログラムがハングアップしてしまうらしく、先に進んでくれません。
変更した部分のプログラムをチェックしたのですが、プログラムにはおかしいところは見当たりません。
ですがとにかく途中でハングアップしてしまうようです。
あれこれ思いつくところをチェックしたりしたのですが、どうにも原因がつかめません。
こういうことになりますと、やはりロジアナの出番でありましょう。
強力な助っ人でありますカメレオンロジアナは本来の当テーマで使用中で、ＵＳＢデータ収集装置に変身しておりましたが、急遽もとのロジアナプログラムを再ロードして、本来の機能に復帰していただきました。
怪しいとにらんだのは［第５６回］で説明しました、ＰＩＣ１８Ｆ１４Ｋ５０とＺ８Ｓ１８０とのデータのやり取りの部分です。
ＲＢ７，ＲＢ６，ＲＢ５，ＲＢ４の４本の信号線を使ってデータの送受信を制御しています。
その各信号をロジアナで捉えて解析してみれば、どこでハングアップしているかがわかるのではないだろうか？
結果はまさにビンゴ、大当たりでありました。
が。
なんじゃあ。こりゃあ。
上の画像はカメレオンロジアナで、Ｚ８Ｓ１８０がＰＩＣ１８Ｆ１４Ｋ５０にＣＰＵ ＲＥＳＥＴの発生を伝えたのに応えて、ＰＩＣ１８Ｆ１４Ｋ５０がＲＢ４とＲＢ５からＬ出力したのを捉えたときのものです。
ＰＲＯＢＥ０３がＲＢ５でＰＲＯＢＥ０４がＲＢ４です。
ＰＩＣ１８Ｆ１４Ｋ５０のその部分のプログラムは、
ＢＣＦ ＰＯＲＴＢ，４
ＢＣＦ ＰＯＲＴＢ，５
でした。
上の画像ではＲＢ４がＬ出力後すぐにＨになってしまっていますが、プログラムではそのようなところはありません。
タイミングからすると、最初に ＢＣＦ ＰＯＲＴＢ，４ の実行でＲＢ４がＬになったあと、ＢＣＦ ＰＯＲＴＢ，５ の実行によってＲＢ４の出力が反転してしまったかのように見えます。
うむむ。
おかしい…。
が、すぐに頭に閃いたのは、今回の見出しにありますＲｅａｄ－ｍｏｄｉｆｙ－ｗｒｉｔｅです。
ＰＩＣのＲｅａｄ－ｍｏｄｉｆｙ－ｗｒｉｔｅについては以前にもどこかに書いたように記憶しています。
ＰＩＣでは出力に設定したポートから入力を行なうと、出力ラッチのデータを読み込むのではなくて、その端子の状態を読み込みます。
それって同じことじゃないの？
と思うのですが、回路の状態によっては微妙に期待したのと異なった結果になってしまうことがあります。
問題は今回の例のように、ＢＣＦやＢＳＦでそのことが無視できなくなる可能性があることです。
ＢＣＦやＢＳＦは機能だけを見れば、そのビット出力のみを０または１にするように思えますが、実際にはそうではなくて、ＰＯＲＴＢならＰＯＲＴＢの全ビットを一度読み込んだ上で指定したビットだけを変化させて、再度全ビットを出力させる、という動作をしているようです。
どうやらその過程で何かがおきているらしい…。
この問題についてＰＩＣ１８Ｆ１４Ｋ５０のＤａｔａｓｈｅｅｔをあらためて読んでみましたら、ＬＡＴＢ（ＬＡＴＡ，ＬＡＴＣもある）というレジスタがあって、ＰＯＲＴＢの代わりにＬＡＴＢを使えばそういうことはおきないらしい、というような記述をみつけました。
［出典］Ｍｉｃｒｏｃｈｉｐ Ｔｅｃｈｎｏｌｏｇｙ Ｉｎｃ．ＰＩＣ１８Ｆ１４Ｋ５０ Ｄａｔａｓｈｅｅｔ
（赤線は筆者）
しかしＬＡＴなどというレジスタは今まで使ったことがありませんでしたからそういうものはちゃんとしっかり検証してから使いませんと、生兵法は大怪我の元と申します。
思わぬ大怪我をしてしまわないとも限りません。
ここはごくごくオーソドックスに
ＣＬＲＦ ＰＯＲＴＢ
としてしまいました。
もともとここはもとあったプログラムを手直ししたためにＢＣＦなどという命令を使ったのですが、何もビットごとに出力しなければならないことはありませんから、そのようにした（ＣＬＲＦを使うようにした）ほうが合理的です。
その結果は下の画像のようにＲＢ４とＲＢ５がともにＬになりました。
これでめでたしめでたしです。
これでつかえておりましたプログラムの変更作業も滞りなく進むようになりまして、前回までに説明しましたようにＣＰＵ ＲＥＳＥＴによるウォームブートが無事機能するようになりました。
しかし。
すっきりしないのでありますね。
なぜ、ＲＢ４が出力反転してしまうのか。
ええ。
Ｒｅａｄ－ｍｏｄｉｆｙ－ｗｒｉｔｅは承知しております。
しかし、どう考えたっておかしいじゃありませんか。
だって、さきほどのＰＩＣ１８Ｆ１４Ｋ５０のＤａｔａｓｈｅｅｔのＩ／Ｏポートのブロック図を見てもわかりますように、ポートの出力はラッチされて端子から出力されていますから、それを読めば同じ値が読み込まれる理屈でありましょう。
ＰＩＣのＲｅａｄ－ｍｏｄｉｆｙ－ｗｒｉｔｅにつきましては、あえて特別な条件を設定して説明されてみえる方もいらっしゃいます。
http://homepage3.nifty.com/mitt/pic/pic1320_06.html
この方はポート出力に０．０１μＦという大きなコンデンサを取り付けて、そのときに発生する問題を説明していらっしゃいます。
そりゃあその通りでありますけれど。
ちょっと苦しいです。
ふつう回路にそんな大きなコンデンサを入れることは無いわけで。
勿論今回Ｚ８Ｓ１８０とＰＩＣ１８Ｆ１４Ｋ５０との間で発生した異常現象はそんなもんじゃないのでありますね。
どこが奇怪かと言いますと、ほとんど説明不能の異常現象だからであります。
今回の一番最初にお見せしたカメレオンロジアナの画像をもう一度よっくご覧になってください。
あまりの奇怪さに背筋がぞぞぞっとしてきませんか？
あ。ＲＢ４とＲＢ５のあたりの回路図は［第５６回］でお見せしております。
それを見ていただければおわかりになりますようにごくシンプルなラインで、どこにもコンデンサなど入ってはおりませぬ。
それでは、なぜあのような奇怪な出力になってしまったのでありましょうか。
ええ。
それが謎だったのであります。
ですからその謎を解明しないことには、このことについて何も書くことができませんでした。
今はちゃんとウラが取れましたので、こうして書いているのです。
説明の途中ですが本日は時間がなくなってしまいました。
この続きは次回にいたします。
ＣＰＬＤ＋ＳＩＭＭを使ってＵＳＢプロトコルの解析を！［第５８回］
２０１４．６．２ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る