オブジェクトコンバーターによるCRC演算の結果出力機能について

> 何か対策方法とかありますでしょうか？

まずは問題の現象が実際に起こっているかを確認されることでしょう。

・ブート側のオブジェクトコンバーターによるCRC演算の結果出力が、フラッシュ側に反映されていないのかホントか

・hexファイルへの埋め込みだけで、ロードモジュールに反映されていないのかホントか

豆大福さん、こんにちは。NoMaYと申します。

以前に別スレッド『ブートプログラムのサブプロジェクト作成』に投稿したプロジェクトで状況を理解しようと試し始めて「それはそうだよな」と気付いたのですが、これはそういう動作でしょうね。

以下はCS+ for CA,CXのCRC演算設定画面の画面コピーですが、CRC演算結果のHEXファイルへ埋め込みは、オブジェクトコンバーターというツールが直接HEXファイルに対して行っている作業のようです。ですので、フラッシュ領域リンク時のリンカでは、ブート領域リンク後に直接HEXファイルに対して埋め込まれるCRC演算埋め込み値は、関知しようが無いことですね。(埋め込まれたことも関知しようがないので、(消えているというより)FFのまま、ですね。) 実は、ぶっちゃけてしまうと、私はフラッシュセルフ書き換えもブート/フラッシュの分割もCRC演算も実務としてやったことがないですが(それにも関わらず豆大福さんにリプライしていますが)、フラッシュ領域側で、ブート領域側込み(ブート領域側のCRC演算値も込み)で、CRCチェックを行う必要があるものでしょうか？(これは必要が無い筈だと言っているのではなく、私の経験不足から聞いていることです。ちなみに、今までリプライしていた人も、たぶん、やったことは無いだろうと私は思います。かふぇルネのその常連さんのスキルなら、画面を見たことがあればすぐに気付いただろうな、と私は思いますので。あと、すぐにリプライして来た人が質問内容/相談内容に関して充分に知っていると思ってしまうのは、かふぇルネでは必ずしも当てはまらないことですので、そこが、かふぇルネの難しいところですかね、、、)

> 私はフラッシュセルフ書き換えもブート/フラッシュの分割もCRC演算も実務としてやったことがないですが

> ちなみに、今までリプライしていた人も、たぶん、やったことは無いだろうと私は思います。

自分ならありますが?

> かふぇルネのその常連さんのスキルなら、画面を見たことがあればすぐに気付いただろうな、と私は思いますので。

CS+ を使用してるかもどうやって複数の hex ファイルを生成しているかも情報出さない人にあらゆる可能性を考慮した上で「もし CS+ を使用されてるなら～」という対応はしないですね。

豆大福さん、こんにちは。NoMaYです。

その後、どうでしょうか？ (以下の件、CRCチェックしなくても大丈夫でしょうか？) もう、このスレッドは見ていないかも知れませんが、、、

＞ フラッシュ領域側で、ブート領域側込み(ブート領域側のCRC演算値も込み)で、CRCチェックを行う必要があるものでしょうか？(これは必要が無い筈だと言っているのではなく、私の経験不足から聞いていることです。

豆大福さん、こんにちは。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