H8/3694 書込み環境 2005.12.26
H8/3694 書込み環境 2005.12.26
|
・ H8 をブートモードで起動し、フラッシュ ROM へプログラムを書込みます。 ・ この書込み環境は次の３つの要素で構成されます。 |
|
|
・ 全書み込操作がパソコンの Key 一発！で可能です。（スイッチ操作不要！） ・ ターゲット（ＣＰＵボード）側にモード切替スイッチとかジャンパは不要です。 ・ パソコンには COM1 ポートが必要です。 ・ ターゲット側に RS232C へのレベルコンバータ（Max232 とか）は不要です。 （H8CPU のピンへの直接インタフェースです CPU 側の回路図 ） ・ 秋月のキットなどの RS232C コネクタへの「直結」はできません。 （RS232C への接続にはレベルコンバータが必要です） |
|
ターゲット（ＣＰＵボード）側の専用コネクタ（6P）とパソコンを、書込みケーブル（アダプタ）で接続します。（アダプタへの電源供給は不要です： RS232C の信号ラインから電力を得て動作します） 
【言い訳…】 現在、パソコン側の COM ポートは COM1 固定です。COM2 とかは使えません。 ・ H8/3694 側の回路 Fw3694if.lzh (55KB 2005.12.19) |
|
書込みケーブル（アダプタ）では、レベル変換（RS232C <--> TTL?）と、論理変換を行っているだけです。ブートモードの起動に必要な RES と NMI を、DTR と RTS で制御することで、フラッシュ ROM 書込み時にジャンパとかスイッチの切替を不要にしています。 
フラッシュ ROM への書込み終了後はパソコンと H8/3694 のシリアル通信ケーブルとして使えます。 ・ 書込みアダプタ回路図 H8fwr2.lzh (31KB 2005.12.19) |
|
書込みケーブル（アダプタ）からの信号を（保護抵抗を経由して）そのま CPU の端子へ接続しています。NMI 信号を CPU ボード内で使用する場合は書込みケーブル側からの信号と合成（負論理 OR）する必要があります。リセット信号も同様です。 
ブートモードの起動には、リセット解除時に P85 が '1' (Hi レベル) でなければなりません。 CPU 側の回路図 をご覧下さい。 【注意】 超低消費電力 CPU ボードの場合、パソコンの COM の信号ラインからの電流回り込みで、CPU ボード側の電源電圧が上昇する可能性があります。電源電圧が 3V とかの場合、ツェナダイオード等で電源電圧の上昇を抑える必要があるかも知れません。 H8/3694 は 3V からの動作が保証されていますが、その消費電流はかなり少ないようです。私の手元には、COM からの回り込み電流だけで動作する CPU ボードがあります！ |
|
書込みに関する全ての操作をＰＣ側より行いますので、書込みケーブル（アダプタ）接続後はパソコン側のキー／マウス操作のみで書込めます！ DOS 版はプログラムファイル名を与えて起動するので、起動後、直ちに書込みを開始します。Win 版は起動後にプログラムファイル名を設定してから書込みボタンをクリックすると書込みを開始します。スイッチやジャンパの操作は不要です。 余談ですが…、H8 のページで公開している「簡易モニタ」を組込んでおくと、書込んだ後、書込みケーブル（アダプタ）をそのまま（接続したまま）にして、COM の通信ソフトを起動すれば、そのまま（ハードに手を触れずに）デバッグ作業へ移ることができます。（この時、書込みケーブルはシリアル通信ケーブルになります） コンパイル（アセンブル）→書込み→デバッグ→コンパイル→ ・・・ とエンドレス？に作業が可能です。 |
|
Win の DOS 窓 で動作します。（Turbo-C です） ユーザブートプログラム名とユーザプログラム名はコマンドラインから指定します。 とりあえず、必要な全てのファイルを同一のフォルダへ格納し、DOS 画面を開いてプロンプトの CD コマンドでそのフォルダへ移動した後、以下のような操作となります。（私は、必要なキー入力を BAT プログラムで用意してデスクトップに置いています） ユーザブートプログラム名が 3694BT20.MOT で、 ユーザプログラム名が USERPROG.MOT の場合、 > FW3694 3694BT20.MOT USERPROG.MOT↓ で、USERPROG.MOT を H8 のフラッシュ ROM へ書込みます。 コマンドラインで指定するプログラムの形式は、モトローラ S か、インテル HEX です。これらの形式（モトローラ S /インテル HEX）は自動で判別しますので、どちらでもかまいません。これは、昔、Z80 用アセンブラ（インテル HEX 形式で出力する）へマクロを食わせて H8 をアセンブルしていた名残りです。（たいした意味はありません：笑） 【注意】 現在、１レコードのデータ数が多すぎると対応できない…という BUG があります。原因は単純でレコードの読み込みバッファ長が不足しているだけなのですが、まだ修正できていません。（１レコードのデータ長が１００以下であれば問題は無いハズですので、通常、問題が発生することは無いと思います） 日立のコンパイラの場合、モトローラ S 形式で出力すれば問題ありませんが、インテル HEX 形式で出力すると、１レコードのデータ長が２５５になるケースがあるようです。（もっとも、誰もそんな事しないと思いますが… 日立のコンパイラでインテル HEX を出すなんて…） 画面表示にエスケープシーケンスを使っていますので、素の DOS で使う場合 config.sys へ ansi.sys を組み込まないと画面がとても見づらくなります。（Win の DOS 窓なら問題ありません） ・ DOS 版プログラム Fw3694dos.lzh (78KB 2005.12.19) |
|
現在 (2005.12.26) 書込みはほぼ問題なく行えるようです。まだ全ての機能が実装できていないのですが、「暫定版」ということで公開させてもらいました。データ転送スピードの UP（38400bps へ）とかはできていませんので、その後のバージョン UP にさせてもらう予定です。 DOS 版とは異なって H8 への書込み時以外は通信プログラムとして動作します。ボーレート変更などの他に RTS / DTR の出力レベル操作、CTS レベルのモニタ、H8 への NMI 発生、リセットなどが可能です。 書込み時、「Write」ボタンは、ユーザブートプログラムの転送済バイト数、その後、書込みブロックアドレスの表示となります。（「動作画面」をご覧下さい） 実行には VB6 の DLL（ランタイム）が必要です（ Vector などからダウンロードできます）。 ［ 動作画面 ］ ユーザブートプログラム転送中 ユーザプログラム転送中 書込み終了 ・ Win 版プログラム Fw3694win.lzh (58KB 2005.12.26) |
|
ユーザブートプログラムは「特定の周波数（CPU のクロック周波数）」しか対応していません。 全ての周波数へ対応したいとは思っているのですが…、個人的には数種類の CPU クロックで事足りる事情もあり、未だに個別周波数毎の対応になっています。 現在、16MHz と 20MHz を用意していますが、これ以外の周波数が必要な方は掲示板にでも書き込んでやって下さい。時間がある時に対応したいと思います。 もっとも（ご存知の方も多いとは思いますが）、リネサスの CPU はかなりタフなようで、少し（かなり？）周波数（書込みパルス幅）が変わっても問題なく動くようです・・・。実際、製品に付属の書込みソフトでは、製品の CPU クロック周波数とは異なる周波数…と思われるモノもあるようです ・・・でも、そんなチップメーカ保証外の行為はキケンです！決しておススメはできません。 ・ ユーザブートプログラム 3694bt.lzh (33KB 2005.10.28) ・ アセンブラ用ライブラリ 3694Lib1.lzh (6KB 2005.12.17) |
|
H8/3694 のフラッシュ ROM 書込み制御では各所にμＳ単位の待ち時間が必要なのですが、この待ち時間をどうやって確保するのか？が問題になるようです。割込みは使えませんから、当然ながらソフトタイマとなるわけで、普通は NOP 命令とかで待ちます。 しかし、例えば CPU クロック 20MHz の場合、４μＳだと 80 クロックが必要で、これを NOP だけで待つと 40 回も NOP を実行する必要があるわけです。で、イラチな私は１命令で 20 クロックほど消費？してくれる MUL 命令を使ったのでした・・・。MULXS は B と W の2命令でちょうど 40 クロックだったものですから・・・（時間待ちに MUL 命令を使うな！とマニュアルに書いてあるわけでも無いし…）。でも、それは 命取り？ だったのです・・・。 最初にハマッたのはベリファイができない！ …という現象でした。プログラムを何度見直しても不信な点は見当たらず、原因不明の間は「なぜ？」の一言が頭の中をぐるぐる回っていました。 で、意を決して、単に LED を ON/OFF させるだけの「絶対に動く（短い）プログラム」を、ベリファイ結果を無視して書込んでみたわけです。結果は想像通りでした。LED はちゃんと点滅していて、プログラムは正しく書込めていたのです。これで、書込みができる事がわかったので、しばらくその状態で使っていた（なんとエエかげんな！）のですが、その後、ベリファイ前の時間待ち部分の MUL 命令が目に入り、それを NOP へ書き直したら無事にベリファイができるようになったという次第です。 フラッシュ書込み時の 時間待ちは NOP にしましょう！ 決して MUL 命令など使ってはいけません！（笑） 他の部分も含めて、どの命令が使えてどの命令が使えないのか？ 興味はあっても…時間が無い…という事で、全てを NOP でのループ（１μＳ）に書換えてフタをしました。 ・・・時間がある方、調べて教えて下さい！（笑） あと、「書込みパルス印加時など RTS 命令の使用禁止！」という制約もありますが、それはなぜなのか？ 使ったらどうなるのか？ 等々、色々なミステリー？がいっぱいです。（それまでの H8 には RTS 命令使用禁止は無かったし…） これって、ヘタなゲームよりよっぽど知的？で面白いと思うのですが、どなたか挑戦されてみてはいかがでしょう？（笑） |
|
ユーザブートプログラムのデバッグ中の出来事でした・・・ 突然、CPU からの反応が無くなりました！ マニュアルのリセットスイッチを押しても何も変わらない…テスト用に点滅させている LED が点灯したままです。（ CPU はリセットが入力されると、出力専用ポートを除いて全てのポートが入力モードになるので、ポートで直接駆動している LED は消えるハズですよね） なんで？と思いつつ CPU の 5 番ピン（リセット端子）をオシロで観察しましたが、ちゃんと Low へ落ちています。でも、…あれぇ〜 リセットができない！ …ということは・・・ついに CPU をやっちまったか…、と落ち込んでしまいました。 しかし…、電源を落として予備の CPU ボードに取り替える前に、念のためもう一度確認しておこう…と電源を入れると、なんと、何事も無かったように CPU が動くではありませんか！ ええっ、どっ…どういう事？？？ この時は狐につつまれた感じでしたが、再現するわけも無く、また想像を越えるような出来事（気のせい？）だったこともあって「不可解」は残ったままでしたが次の作業へ移りました。 しかし、その後で同様の現象に２回（計３回）も出合って、ひょっとしてマイクロコードの・・・・・と考えるようになりました。だいぶ後になって機会があり、リネサスのセミナー講師の方に状況を説明したのですが…。いただいた回答は「基本的にリセットが効かなくなるなんて有り得ない！」との事でした・・・。 でも、個人的な感想として「 H8/3694 のブートモードのマイクロコードには 間違いなく何かあるのでは？」と思っています。リセット信号というのは最上位の例外処理信号ですし、それをマスクする要素は電源ＯＦＦ以外に存在しないハズです（流石の H8 も電源が無ければ動けない！）。電源が入っているのにリセットが効かない・・・これはマイクロコードしか無いだろう・・・というのが私の（素人の）推測です。時間があれば是非とも詳しく調べてみたいところです。（笑） もっとも、個人的な「勘違い」の可能性も 100% の否定はできませんが…。 いやぁ CPU って本当に面白い ですね！！！ |