日記みたいな何か

前々からPICのコードを書いていて気になっていたことの1つに、GPIOを入力から出力に変えたとき、なぜかデフォルトで1になっている場合があるというのがあったりするんですが、PICのマニュアルをよく読んだら何か書いてありました。理解が間違っていなければ、以下のようです。

• GPIOの出力ポートの値をBCF命令もしくはBSF命令で1bitずつ変更する場合、GPIOからの出力用のデータを保持したラッチをRead-Modify-Writeをすることになる
• Read-Modify-WriteのReadのときに、GPIOに入力属性のポートがあると、そのポートについては外から入力されている値を読み込んでしまう (出力属性のポートは、出力している値が読み取られる？)
• Read-Modify-WriteのWriteによって、入力属性のポートから読み取った値が、出力用のデータを保持したラッチの、そのポートに対応したビットに設定される
• 後々になって、入力属性のポートを出力属性に変えると、上記でラッチに設定された値が初期値として出てしまう

これが正しいとするなら、GPIOを出力に変える際の初期値をコントロールするには、まず入力属性の状態のうちにそのポートの初期値を設定して、その上で、そのポートだけを出力に切り替えればよいのかな。必ず1ポートずつ操作する感じで。

これまでの実験結果などから考えると、CPS1の起動時キー書き込みをやってチキチキボーイズが起動しなくなるのは、CPS-A-01がデータバスに信号を流してくるタイミングで、PICが衝突回避のためにGPIOを入力に切り替えているからっぽいですね。その場合、こんな感じの波形が出てくるわけで、CPS-A-01によるバス操作が、(たとえ一瞬であっても)そのままCPS-B-21に認識されちゃうんだと思われます。

ていうか、普通に考えたらそうですよね。何でこれでいけると思ったんだっけ・・・（汗）。あー、当初はCPS-A-01がバスアクセスしている中でも起動時キー書き込みに成功していたからそう思ったのか。今考えてみると、あれはPICのGPIOを出力属性にしたままで、さらにデフォルトはLOWにして書き込んでいたから、そのタイミングでCPS-A-01がデータを流しても、バス上の信号はLOWのままとなり、影響を受けなかったということなのでは・・・。データをデフォルトHIGHにしたら不安定になって、クロックをデフォルトHIGHにしたらまったく起動しなくなったのも、これと辻褄が合いそうです。で、今回、律儀に衝突を避けるようにしたことで、CPS-A-01のアクセスが100% ノイズとして割り込むようになり、キー書き込みの前のロック解除すらうまくいかなくなった、みたいな。

PICのGPIOは出力にしたまま、デフォルトLOWとして、バスアクセスのタイミングだけCPS-A-01とずらすというやり方をすると衝突の影響を無効化できる可能性はありそうですが、多分電気的によろしくない状態ですよね。うーん、やはりバスに横付けする形の起動時キー書き込みは諦めて、当初のようにキー書き込み中はデータバスをBボードから切り離すことにすべきか。この1週間、何も得られなかったわけではないのが救いですが、かなり無駄なことにエネルギーを注いてでしまいましたな。はぁ。

CPS1の信号回りを見ていて、ふと気になってロジアナの設定を確認したところ、トリガレベルがTTLになっていました。もしかして、これ、CMOSレベルで見ないとだめだった・・・？とりあえず、PICが何もしていないとき、普段はHIGHになっていたデータバスが、スレッショルドが変わったことでLOW表示になりましたｗ

で、今日は、CPS-A-01によるメモリアクセスを避ける上で、OBJEOに代わってHSYNC同期できないか実験してみました。OBJEOだとトグルする回数が少ない関係で、これに同期しちゃうとどうしてもCPUリセット解除までにできることが限られてしまうんで。HSYNCなら60μ秒程度の周期でずっと出続けているはずです。

Cボードの116番ピンから信号を引き出して観測してみると、HSYNCはOBJEOと同じくらいの時間LOWになっていることが判明 (波形のグレーがHSYNC、紫がOBJEO)。CPS-A-01によるデータバスへのアクセスタイミング (波形の緑と青) とほぼ同時にHIGHに戻ってる感じですが、ここを狙って同期すれば、PICの遅さも相まって、ちょうどいい感じに処理を挟めそうです。

HSYNCに同期してキーを書くようにし、さらにメモリアクセス競合を避けるようにプログラムを修正してみたところ、チキチキボーイズでも起動してくれました。ただ、不安定で、ダメなときも多めです。

波形を観察してみると、今まで見てきた通り電源投入直後からデータが流れまくるパターンと、逆に一切データが流れないパターンの2種類があることがわかりました。後者のようなケースになる場合があったとは気が付かなかった・・・。そして、後者のパターンに当たるとうまく起動して、逆に前者のパターンに当たると起動しない傾向にあるようです。うむむ、これはもしや・・・。

CPS1の起動時キー書き込みに関して、昨日試したOBJEOに同期させた方式を実用化すべく、CPUリセット解除前にデータバスに余計な信号が流れない殿様の野望2の基板を利用して、既存のコードを段階的に変更。が、修正とテストを繰り返していたところ、突然ある変更で動かなくなり、その後、さっきまで動いていた状態にまでコードを戻しても動かないみたいな事態となってしまいました。まさかと思いながらもPICを別個体に替えたら改善。PICがヘタったのか・・・？

そして、別個体で実験を継続してわかってきたんですが、キー書き込みに使うデータ信号をデフォルトHIGHにして、書き込むタイミングで正しい値に設定するようにするとキー書き込みが不安定になるようです。さらには、クロック信号の方をデフォルトHIGHにするとまったく動かなくなるという謎現象も。うーん、ちゃんと回路的に問題ない動きになってると思うんですが、何でダメなのか・・・。うーん、苦しい。

CPS1での起動時キー書き込み、何かしらのCボード近くの信号を見張ってタイミングを合わせることで、CPS-A-01によるバスアクセスとの衝突を回避できるのではないかと考え、調査・実験してみました。それっぽそうな信号をいくつか見てみたところ、Cボードの56番ピンに来ているOBJEOというCボードへの入力信号が、(フレーム境界と思われる一部の期間だけですが) ちょうどCPS-A-01によるデータバスアクセスが発生するタイミングと同じようなタイミングで数マイクロ秒ほどHIGHになるようです (波形の黄色の信号)。

というわけで、試しにこの信号をPICのGP3でポーリングして (PIC12F509には割り込みとかがないので・・・)、これに同期する形でデータバスを操作するようにコードを修正。結果、PIC12F509の処理能力でもいい感じに同期できて、OBJEOが1回立ち上がるたびに1回クロック信号を上げ下げできることを確認できました。写真の紫の波形がOBJEOで、緑がクロックです (ここではクロックやデータを、デフォルトでHIGHの状態にしてします)。

ただ、次に書き込む1bitのデータの用意に結構時間がかかるようで、このときはOBJEO 2周期分かかってしまうようですｗ。一応、OBJEOに同期しても、CPUリセットが解除されるまでの300ミリ秒の間に書き込みは終わるようですが、ギリギリですね・・・ (波形の黄色がHIGHになっている期間がキー書き込み期間で、右下の緑と青で塗りつぶされているところがCPUが動き出したところ)

CPS-A-01が起動直後に、どの状態になったことでバスを触ってくるのか調べるために、内部状態と関係する信号が出ていそうな112番ピンから116番ピンまでを観測してみることにしました。こんなときも秋月電子のピッチ変換基板が役立ちますｗ

信号を観測した結果、WSTOBJ信号が定常的に有効になっているということがわかりました (写真の波形の緑色)。どうやらCPS-A-01はCPUリセット解除前に、WSTOBJ状態になってメモリアクセスを引き起こしているようです。この状態は垂直5スキャンライン分を除いて、毎スキャンライン遷移するようです。

そしてもう一つ、大事なこともわかりました。これまで見てきた波形から、起動直後、データバスにデータが出てくるケースでも、データがまったく流れない隙間の時間帯が広く存在すると考えていたんですが、どうもこれは間違いだったようです。適当なロジアナの内部クロックではなく、きちんとCボードに供給されている16MHzのクロックを参照して波形を取ったところ、WSTOBJ信号は、起動直後から常にトグルし続けており、データ転送も60μ秒程度の間隔で常時発生していました。

上の波形からもちょっとわかるかもしれませんが、隙間は16.6ミリ秒周期でわずかに300μ秒程度発生しているだけのようです。これはおそらく、CPS-A-01がWSTOBJ状態にならない5スキャンライン分の時間と思われます。これまで数十ミリ秒単位でデータバスに信号が流れない時間帯があるように見えていたのは、サンプリング周波数が100KHz程度と低すぎたことで周期的に信号を取りこぼすフェーズが現れ、それがデータが流れない時間帯のように見えていたということなのかもしれません。はぁ・・・。

で、改めてどうするか考えてみたんですが、これまでも、こんな状況の中、CPS-A-01のメモリアクセスを気にせずキーを書き込んだ場合、特に問題なくキーが書けていました。ということは、一瞬データが流れるくらいなら、セキュリティの書き換えに影響しないのかもしれません。そうだとすると、CPS-A-01がバスにデータを流すタイミングを避けながらキーを書き込めば、データの衝突を回避しつつキーを書き込める可能性がありそうです。これを狙ってみたいと思います。 (追記: 後々になって、これは誤解とわかりました。キー書き込み中、マザーボード側に起因するCLK信号のトグルが混ざると、それが一瞬でも起動しなくなるようです。衝突しながらも起動時キー書き込みが成功していたのは、PICの信号が出力に入りっぱなしになっていることで、衝突時にPIC側が勝っていたからだと推測されます)