開発日記

休止期間も含めて3か月もまともに動作しなかった LZ93D50 とその周辺の対応の大半がようやく終わった. variant が2つあってそれはまだ対応してない.

問題その1/未完: write cycle で MCU が死ぬ

CPU_RW の配線が不適切だったので OR gate をいれて修正したことで発生頻度がとても下がったが、まれに起きるので完全に直ってないと思う.

問題その2/完了: register への write cycle を認識しない

register への write cycle の前には必ず read cycle がいる.

問題その3/完了: read cycle と write cycle を1度に含めると通信がおかしくなる

長らく動作不安定の原因として悩まされたもの. 原因究明が問題その1と問題その3の切り分けに相当時間がかかり、カートリッジに関係なく MCU 単体で問題が発生する.

MCU のソフトの実装が悪いまではわかったものの、明確におかしい場所の特定ができなかった. おかしい場所は3つの送信処理を3つにわけていたのでうち2つを1つにまとめて送ることで直りそうな気がした. その後も原因特定ができなかったので直る保証がないまま実装したところ問題その3は起きなくなった.

問題その4/完了: 静的なバッファ管理の限界

問題その2とその3の対策として複合的な問題. MCU へ送る命令は複数記載できるものの容量は 0xc0 bytes, ROM dump での容量は 0x400 bytes と固定になっていた. これで問題その2の dummy read を実装した上で EEPROM を効率的に制御しようものなら 0xc0 bytes は少なすぎる. そして ROM dump の buffer はこのときはそんなにいらない.

また backup RAM (パラレルのSRAM) write でも同じ問題があり、その場しのぎに無茶castしてたが限界を感じたので動的な確保をすることにした. これに関して MCU 内部に各種 alignment 制限があるので動的管理領域を100%使い切れることはないが、柔軟性が増えた.

問題その5/新規: MCU の ROM 容量の限界

firmware を修正したり効率的な機能を実装していったら残り 0x1000 bytes を切ってしまった. RAM では場合によって使わない部分は動的管理すれば資源はわりと使い回せるが、 ROM ではそういうことができない.

もうちょっと機能を追加したいのでそれができた場合に使用率95%では将来性が全くない...

問題その6/新規: flash programming の再実装

問題その4やその他の過程で flash programming に関する RAM 管理や今見ると不必要に複雑で何をやっているかわからないコードをいったん捨てて実装したのでちゃんと動くように戻す必要がある.