NVM user row による BOD33 Level 初期値は 0x07 でこれはデータシート通り.
ただし BOD33.LEVEL 値は日本語訳の古めのデータシートだと 1.7V 前後であり、これはおかしい. 新しめの英語のデータシートだと値 7 の記述は削除されており、 48 に設定するほうが無難だと思われる.

本当に BOD level が 1.7V であれば問題は頻発するはずなのに LZ93D50 にだけ発生する理由は不明.

ソフトウェアバグとして調査を進めたところ、 MCU が送信したデータを PC が受信してないことが判明. とまり方に2通りあり、MCU から送信したものの送信完了割り込みがある場合とない場合. 止まり方としては変数は違うが、ソフトウェアとして止まるという理由にはなっていないと判断.

筆者の環境では LZ93D50 のカートリッジのみ発生するが、別のカートリッジでは発生しないのでソフトウェアが原因で不具合が起きるとは思えない(*). ハードウェアが原因として再調査するが、筆者の機材と知識が貧弱で調査効率が落ちることが懸念される.

• ただし筆者の環境が正しいものではなく、どの環境でも安定動作が求められる.

筆者の環境では CHARAROM の bank 切り替えの後だけ不具合が起きるので理由を調べるために LZ93D50 ではないカセットをさして LZ93D50 用のドライバで動作させたところ、同様の不具合は起きた. LZ93D50 のカセットがこの不具合の原因では無いことが判明.

LZ93D50 の CHARA bank 切り替えは複数の bank register を1度に書くまではほかの driver と同じだが write cycle 認識前に read cycle をいれる必要がある. read cycle の data を送信するあたりで止まってしまう.

現状ソフトウェアなのかハードウェアなのかは不明ではあるが LZ93D50 のカセットが通信をとめる原因ではないことが判明.

下記の対策をすれば改善できる.

• read cycle が必要になってしまう原因の解析をして、標準の write cycle に組み込む.
• この read cycle は送信する必要がないものなので、送信しない設定を設けて回避する.

BOD33.level の値は 48 に設定してからは不具合は起きていないので assert は発生していない.

bank 切り替えができない理由について. 2つの計測では下記の順に memory cycle を行う.

• CPU address $8000, data $FA
• CPU address $8001, data $FB

Console 3 spi/memory の場合で、lz93d40.cpu_rw = cpu_rw とした場合はすべての write cycle を認識しない. lz93d40.cpu_rw = Decoded_rw として場合は CPU address $8000 のほうだけ認識する.

この2つを比較すると図で丸く表した cpu_phi2 の部分が重要で前者は lz93d40.cpu_rw = L なので write cycle, 後者は cpu_rw = H なので read cycle になる. これは 3 spi/memory の設計上発生してしまうものでそれがうまく動いてしまっている.

driver 4 spi/memory の場合は address $8000 の事前に cpu_phi2 が動いていないので write でも read でもない (ppu_rd が下がってるのは設計上あまりよくないが今回は無視する).

この3つを比較するとLZ93D50 の write cycle の認識には事前に read cycle が必要だと思われる. ただ、 driver の場合は確実に read cycle があったので直前でないと認識しないのは少し謎. しかし実際の 6502 では write cycle の前に read cycle が絶対に存在するのでこちらの実装が不適切と考えるべき.

lz93d50_console.png (24,385 bytes)   

lz93d50_console.png (24,385 bytes)   

lz93d50_driver.png (24,212 bytes)   

lz93d50_driver.png (24,212 bytes)   

問題を発生させない実装に関して.

• driver でわざと dummy read を抜いているのに 4 spi/memory になっているのはバグなので要調査(mruby レイヤだと思われる).
• dummy read は必要であるのでこれは回避できない.
  ROM dump に関してはこのデータは必要ないので送信しなければ、MCU の通信がおかしくなることはない.
  backup RAM read では serial EEPROM のため read と write をかなりまぜてデータを得るべきなのでこの実装を安定させないと正しく動作しないことが予想される.

容疑としては BOD reset と complex memory cycle のあとに PC へ送る USB が送信完了待ちにならない点.

BOD reset は設定値を変えてから起きなくなっている.

送信完了待ちになる理由は実のところ不明ではあるが、 read data を PC へ送るデータが最小で3つ連続に分割されていて効率が悪く、ここで問題が起きていることが確実になったため.

最小3つのデータは下記になっている.

• 通信用ヘッダ (10 bytes)
• read data (ROM read の場合最大 0x400 bytes, register write の場合 1 から 8 bytes)
• 通信用ヘッダ (10 bytes)

このデータの最初と2番目を統合して1度に PC で送ると動作は安定した. またこの実装に伴って、buffer RAM の構成を見直して[read data 最大 0x400 bytes ]を[ヘッダを含めて read data 最大 0x4c0 bytes]にしてループ回数を削減した.

block EVSYS について DMA の接続に対し再同期バスが必須であるという記述に気づいた(長い間見落としていた). 再同期バスを設定する過程で EVSYS による大量の DMA 制御ができない場合に、送信待ちでいつもの assert が出る確率が非常に高かった.

再同期バスの設定は完了したので、assert がでないか経過をみる.