使用デバイス：RL78/G13,G14
開発環境：CA78K0R
プログラムコードの領域をブート、フラッシュの2領域に分割して開発を行います。
ブート領域はスワップ機能を使わず、16KByte固定として残りをフラッシュ領域に割り当てる形としたのですが、
ブート側のオブジェクトコンバーターによるCRC演算の結果出力が、フラッシュ側に反映されていないように見えます。
多分hexファイルへの埋め込みだけで、ロードモジュールに反映されていないのが原因とは思いますが、
何か対策方法とかありますでしょうか？
豆大福さん、こんにちは。NoMaYです。リプライどうも有り難う御座います。以下の目的ということで私が思ったのは、ブート領域部分だけのCRCをブート領域のMOTにオブジェクトコンバータで埋め込み、かつ、フラッシュ領域部分だけのCRCをフラッシュ領域部分のMOTにオブジェクトコンバータで埋め込み、そうしておいて、ブート領域のプログラムで2つの領域それぞれに対し別々にCRCチェックを行い、それぞれで良否判定して2つともOKなら良しとする、というのでは駄目なのだろうか？ということでした。そういうやり方(2つの領域に対し別々にCRCチェックを行い2つともOKなら良しとする)のでは駄目なのでしょうか？＞ そこでROMに異常が生じた場合、フラッシュ側で異常が生じたのか、 ブート側で異常が生じたのか、切り分けをしたいと考えたわけですが、 フラッシュ側だけだと、どちらに異常が生じたか簡単に切り分けができない。
豆大福さん、こんにちは。NoMaYです。ハードウェア高速CRC演算器が内蔵されていたことを思い出して、ハードウェアマニュアルを見てみたところ、合点がいくようになりました。演算範囲の先頭が0番地固定なのですね、、、
豆大福 さんほや です。こんにちは。
諸々百も承知だと怒られそうですが…
オブジェクトコンバータはロードモジュールからバイナリを抜き出してHexファイルを吐き出すもので、ロードモジュールに書き戻す事はしていないはずです。デバッガでロードモジュールをダウンロードしてもCRCが入っていないのはそのためでしょう。
デバッガで見る時には、Hexを書込みまたはデバッガでダウンロードした上にシンボル情報だけをロードモジュールからダウンロードして動かす必要があります。
また、事前に取り決めておいた固定番地にCRCが配置されるようにさえしておけば、それがフラッシュ側にあろうがブート側のアドレス範囲にあろうがやる事は変わらないと思います。
豆大福さん、こんにちは。NoMaYです。RL78/G13,G14の高速CRC演算器を使うのかな？というのは、こちらの先走った仮定ですけど、豆大福さんの昔のスレッド『DTCを使って汎用CRC演算機能を使用することはできますか？』を読むと、汎用CRC演算器について御存知の上で今回質問されているようなので、やはり高速CRC演算器を使う前提の話かな？という気がしました。(高速CRC演算器の仕様は下の画面コピーの通りですね。)これもこちらの先走った仮定(というか勝手な推測)ですけど、同じようなことを考えたユーザさんが取っているであろう方法は、ファイル管理上よろしくないと思いつつも、ブート領域の最後にconst far uint8_t型で2バイト分の配列を配置し、オブジェクトコンバータが生成したMOTファイルのCRC値の下位バイトと上位バイトをエディタで手作業でソースファイルへコピペしているのではないかと思います。(つまり、全体で2回ビルドして、1回目のビルドで得られたCRC値をコピペして、もう1回ビルドして、ブート領域のlmfファイルを確定させている、のではないかと思います。) また、Perl/Ruby/Python等が使える人の中には、こういったスクリプト言語でコピペ作業を自動化した人もいるのではないだろうか、とも思います。RL78/G14 ユーザーズマニュアル ハードウェア編からの抜粋www.renesas.com/jp/ja/search/keyword-search.html#genre=document&q=r01uh0186
> 対応できると思いますが、
以下、自己レス。
CS+ for CA,CX V4.03.00 [07 Jun 2019]
CA78K0R V1.72
を使用して、 とリンクされている資料を参考に、ターゲットをフラッシュサイズ 64kB の RL78/G13 に対して
ブート領域: 00000～01fff
フラッシュ領域: 02000～0ffff
の設定でプロジェクトを作成し、ブート領域の最後とフラッシュ領域の最後にそれぞれの CRC を計算して配置する変更を加えてビルドを行ったところ、特に問題等なく HEX ファイルに CRC が設定されているよう見えます。
japan.renesasrulz.com/.../3005.bootAndFlash.zip
↑確認を行ったプロジェクト丸ごとアーカイブ
デバッグ・ツール(シミュレータ)にロードをしてメモリダンプをしてもそれぞれの CRC の値は設定されていることが確認でき、問題なさげであったことをご報告しておきます。
豆大福さんのやりたい事は分かりました。
ツールの設計思想として、フラッシュ丸ごとのCRCが計算できれば、OKということでbootのCRCと丸ごとのCRCの2段階でCRCを取ることは考えていないようですね。
CS+でやるならアセンブラでBOOT部のCRCをdb命令で埋め込めばlmfにも反映されるようです。
BOOT部はそうそう修正は入らないと思いますから、通常の手順でHEXにCRCを付加する設定をして、オブジェクトコンバータで出力されたCRCの結果をアセンブラで定義しなおせば全体コンパイル時にBOOTのCRCも取り込まれます。(更新時はCRCの再設定を忘れずに)
↓CRCをデバッグする場合の設定(CRCが埋め込まれたHEXを追加で読み込めば、CRCがメモリにロードされます。)