長らく放置してしまったEEPROM問題ですが、解決(というか原因判明)したのでその顛末を記しておきます。
まず前回の最後に書いた試してみたいことですが
- EMILY Boardのファームウェアを古いものに戻してみる
→ 状況変わらず - AT24C64に交換してみる
→ 部品は調達したのですが未実施 - TWI(AVRのI2Cインターフェイス)のステータスを表示してみる
→ ステータスの意味を調べ中 - I2Cバスの波形を観察してみる
→ 立ち上がりが遅いように見えたのでレートを320kHz→100kHzに下げてみたが状況変わらず
といった結果でした。
前回書いたようにオートロードが有効になっていますが、ふとオートロードを切ってみたらどうなるだろうかと試してみることにしました。とは言えEEPROMアクセスができないので簡単に切ることができません。そこでオートロードを無効にしたファームに書き換えてみたところ、現象が消えてしまいました。EL
コマンドで手動ロードを繰り返してみても問題は起こりません。
オートロードと手動ロードで何か処理が異なっているのかと調べてみても違いは見当たりません。唯一違いと言えるのはオートロード後にターゲットCPUのリセット解除して動作させているくらいです。それがEEPROMのアクセスと関係するとは思えないのですが……
そこで念の為オートロードを再び有効にし自動実行だけを切ってみたところ、やはり問題はおきませんでした。
これまでEEPROM(というかI2Cバス)アクセスのコードに何か問題があると思っていたのですが、どうやら問題はそこではなかったようです。
ということで何でターゲットCPUが動作しているとEEPROMアクセスができないのか、いろいろ考えていたのですが……
I2Cバスの信号とメモリのRD, WRが隣接してしまっているのが原因と思われます。
ターゲット基板にEEPROMを載せようと思ったのは2枚目のTLCS-90ボードからで、コネクタの空きピンに押し込んでしまったのが裏目に出たようです。
と原因は分かったのですがドン詰まりです。既に多数のボードを作ってしまっているので今さら変更は困難ですし、そもそもGNDに挟もうとしたら大変更になってしまいます。
ターゲット動作中にアクセスしなくてはならない状況はあまり無いので運用でカバーするしかないかなと考えています。
コメントを追加