L(oad)コマンドとH8/SHのSCI

忘れていましたがSuperH版とH8/300版からUniversal MonitorのL(oad)コマンドの仕様を変更しています。

1. これまでサポートしているレコード（Intel HEXの00,01・S recordのS1,S9）以外の動作は不定でしたが、未サポートのレコードは読み飛ばすように変更しました。チェックサムの確認も行なわれません。
2. S recordの24ビットアドレス（S2,S8）と32ビットアドレス（S3,S7）を新たにサポートします。

1.はすべてのプロセッサに、2.は64kBを超えるメモリ空間を持つプロセッサに展開したいところですね。

あとIntel HEXの02,04レコードも対応したいところです。セグメントの02は8086系以外ではあまり意味がないでしょうから8086版のみ、32ビットリニアアドレスの04は上記2.と同じように64kBを超えるメモリ空間を持つプロセッサで対応すれば良さそうです。

さて、この新仕様のL(oad)を先に実装したSuperHでテストをしていた時です。

正常なファイルのロードはすんなり動いたのですが、チェックサムエラーの検出テストを行なうとなぜかハングアップしてしまいます。エラーメッセージ表示後はそのままプロンプトを表示してコマンド待ちに戻るだけなのでハングアップの要素はほとんどありません。

当初はスロット不正命令などを疑って確認しましたが問題ありませんでした。そもそもスロット不正命令ならアセンブラが警告するはずです。

その後表示をよく見るとプロンプトも表示されており、L(oad)コマンド固有のルーチンは抜けていることがわかりました。

とするとハングアップしているのではなくコンソールからの入力ができなくなっていると考えるほうが自然です。

それでもう一度ユーザーズマニュアルのSCIのところを読み直したところオーバーランが発生すると受信動作が停止することがわかりました。受信を続けるためにはこのオーバーランのフラグをクリアしてあげないといけません。実際CONINルーチンの中でクリアするように変更すると問題は解消されました。

何が起きていたかというと以下のようなことが起こっていたと推測されます。

1. チェックサムの2文字を受信したところでエラー判定
2. エラーメッセージを表示
3. メッセージ出力中も末尾の改行コードや次のレコードは送られてくる
4. メッセージ（とプロンプト）の出力が終わるまで受信のCONINは呼ばれない
5. オーバーラン発生

割り込みで受信FIFO構成していればトラブルにはならなかったんですが、シンプルに動かすことを目指していますから...

これまでにシリアルの石はいろいろ動かしてきましたがオーバーランでレシーバ止まるのはこれが初めてじゃないかな。H8のSCIも同等なのでこちらは最初から対策入れて問題ありませんでした。実は他のチョンボはありましたが...