Renesas RX Series Programmer Version 1.90
Copyright (C) 2016, 2024 Hiramatsu Kunihito (hira@rvf-rc45.net)
usage:
rx_prog [options] [mot file] ...
Options :
-P PORT, --port=PORT Specify serial port
-s SPEED, --speed=SPEED Specify serial speed
-d DEVICE, --device=DEVICE Specify device name
-e, --erase Perform a device erase to a minimum
--id=ID[:,]ID[:,] ... Specify protect ID (16 bytes)
-r, --read Perform data read
-v, --verify Perform data verify
-w, --write Perform data write
--progress display Progress output
--erase-page-wait=WAIT Delay per read page (2000) [uS]
--write-page-wait=WAIT Delay per write page (5000) [uS]
--device-list Display device list
--verbose Verbose output
-h, --help Display this
rx_prog の歴史的背景
RX マイコンのフラッシュ書き換えに、独自に実装したプログラムを保守、管理している。
「Renesas Flash Programmer」があるのに、何故？と思われるかもしれないが、歴史的な背景がある。
最初は、コマンドラインから動かせるとか、マルチプラットホーム（Windows,Linux,OS-X）とか、色々な理由があって、少しづつ機能追加していって、現在の姿になっている。
R8C/M120AN マイコン用のフラッシュプログラマーを実装したのもあって、「RX マイコン用も欲しいなぁー」と単純に思ったのも要因としてある。
なので、同じように使えるような仕様にしてある。
自分は、どうも GUI の操作が面倒だと感じる、複数のマイコンを試す場合など、R.F.P.では、プロジェクトを開き直す必要がある。
又、マルチプラットホームで動作するようにしてあるので、個々に専用の設定キーがあったり、色々な環境で使い回すのに都合が良いように工夫してある。
ただ、現状、機能的には完全では無い。
RX26T のサポート
RX26T は、今までの RX マイコンと異なり、書き込むページサイズが 128 バイトとなっている。
※以前は 256 バイト
その仕様に伴い、細かく色々変更したものの、何故か、書き込みに失敗する不具合があり、長い間、ほったらかしていた・・
丁度良い機会だったので、不具合の原因を調べてみたー
ところが、中々原因が掴めない。
結局、「erase_page」にバグがあり、それが引き金となり、ちゃんと消去されていない為、書き込みに失敗する事が判った。
この原因を見つけるのに、かなり時間を使ってしまったが、ちゃんと動作するのは嬉しいのものだー
これで、手持ちの RX マイコンは全て、サポートして、動作実績がある事になる！
※RX65x は、ボードを作って無いので、試せていないが・・・
RX220 の erase_page で不具合
RX220 は、ID コードプロテクトをしていない状態だと、ブートモードでデバイスと接続して、P/E モードに入ると、自動でフラッシュを消去してくれる機能がある。
※P/E モード： プログラム、イレース モード
※このような仕様は、RX220 に限らず、RX24T、RX63T など、少し古いデバイスでは、そのようになっている場合がある。
※その為、「erase_page」の機能をちゃんと実装していなかった。
又、消去されている、されていないに限らず、必ず「消去」コマンドを発行する事で、プログラムの書き込みに関する手順を一般化出来るので、消去の機能を省くのは良くない。
今回、そのケアも行った。
ただ、古い、RX マイコンでは、フラッシュのプログラミングプロトコルが、あまり洗練されていない事がある。
RX220 のハードウェアーマニュアルを読み、「erase_page」の実装を行い、実験すると、エラーで消去出来ない。
エラーのステータスを調べると、「ブロック番号エラー」となっている。
「ブロック番号」とは、RX220 の解説によると、2K バイト単位で、128 ブロックあると書かれている。（256K品）
※「36.4 ブロック構成」
ところが、この仕様に沿って、適切なブロック番号を渡しても、エラーとなる・・
そもそも、ブロック単位が 2K バイトって「変」だよな・・と思って、デバイスの接続時に、取得するエリア情報を観てみたー
#01/26: Area: FFFFF000, FFFFFFFF
#02/26: Area: FFFFE000, FFFFEFFF
#03/26: Area: FFFFD000, FFFFDFFF
#04/26: Area: FFFFC000, FFFFCFFF
#05/26: Area: FFFFB000, FFFFBFFF
#06/26: Area: FFFFA000, FFFFAFFF
#07/26: Area: FFFF9000, FFFF9FFF
#08/26: Area: FFFF8000, FFFF8FFF
#09/26: Area: FFFF4000, FFFF7FFF
#10/26: Area: FFFF0000, FFFF3FFF
#11/26: Area: FFFEC000, FFFEFFFF
#12/26: Area: FFFE8000, FFFEBFFF
#13/26: Area: FFFE4000, FFFE7FFF
#14/26: Area: FFFE0000, FFFE3FFF
#15/26: Area: FFFDC000, FFFDFFFF
#16/26: Area: FFFD8000, FFFDBFFF
#17/26: Area: FFFD4000, FFFD7FFF
#18/26: Area: FFFD0000, FFFD3FFF
#19/26: Area: FFFCC000, FFFCFFFF
#20/26: Area: FFFC8000, FFFCBFFF
#21/26: Area: FFFC4000, FFFC7FFF
#22/26: Area: FFFC0000, FFFC3FFF
やっぱりね・・・
このリストによると、FFFC0000～FFFF7FFF は 16K 単位で、
FFFF8000～FFFFFFFF は 4K 単位であるようだ・・・
この事実に沿って、ブロック番号を指定したら、ちゃんと消去出来たー
マニュアルの嘘は勘弁して欲しい～、これは、あまりに酷いので、報告しておこうかな・・・
RX231/RX24T の書き込み速度
最近、RX231、RX24T の書き込みで、途中ストールする場合が多くなった・・・
この症状は、ページライト時に、十分な遅延が不適切で、書き込みデータを転送出来ない場合に起こると思われる。
そこで、通常の倍、遅延を取るように common/makefile に指示した。
※「--write-page-wait=15000, --erase-page-wait=4000」
ブランク・チェック
主に、RX200 系や、古い RX62x 系、RX63x 系では、ブランクチェックの仕様が古く、全体が消去されているか、いないかしか判らない。
rx_prog は、書き込む際、書き込むデータのマップを 256 バイト単位で作成して、必要な領域のみ、消去するようにしている。
又、ID コードが無指定の場合、デバイス接続で、自動で消去される仕様なので、ブランクチェックを行い、全体が消去されていたら、余分な消去操作を行わないようにした。
さらに、消去領域は、広いので、一旦消去されたブロックに対して、何度も消去操作が発生しないようにした。
まとめ
マイコンの違いで、手順を完全に分けているが、マイコンが異なっても、同じ手順で重複している物がかなりある。
現状では、これらは、コピー、ペーストになっていて、保守性が最悪な状態だ・・・
次は、これらの仕組みを整理してまとめようと思う。
又、まだサポートしていない機能が色々あるのでそれも何とかしたい・・
- Config memory への書き込み
- プロテクト ID の書き込みと管理
- 読出し機能と管理など
- 詳細なエラーレポート
