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

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

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

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

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

ご返信ありがとうございます。

判断に至った経緯を書いておきますと、
①ブート側のhexファイルにはCRC結果が含まれている。
②フラッシュ側のhexファイルにはブート側のCRC結果が含まれていない。（FFになって消えている）

フラッシュ側はブート側のロードモジュールを読み込んで作りますから、
ロードモジュールの引き継ぎデータに含まれていないのではないか、と判断したという事です。
なお、デバッガで確認しても意味はないので、その点は見ていません。

In reply to 豆大福:

ツールの設定はどうされてますか?
あと、hex ファイルのフォーマットに何を使用されてるのかわかりませんが例えばインテルhexは後ろのレコードで前のレコードの値を上書きできる動作だったと思います。目視確認に絶対の自信でもない限りは

> デバッガで確認しても意味はないので、その点は見ていません。

決めつけは危険と思います。

>ツールの設定はどうされてますか?
CRC演算を行う、結果出力アドレス、演算の範囲、演算方法の4項目を設定をしてるだけです。
hexファイルはモトローラです。intelは見辛いので使いません。

>決めつけは危険と思います。
必要なのはデバッグ時ではなく、hexファイルの出力結果ですので。
そもそも今回のCRC演算は仕様上、通常のデバッグ時はエラーになりますし。

すみません、上の書き込みの「大口」というのは私です。

In reply to 大口:

結局どうされてるのかサッパリわかりませんでしたが、ルネサスのFAQにCC-RLで2つのエリアに対してCRCを設定する方法が掲載されているので参照されてはいかがかと思います。
CC-RLはCA78K0Rのオブジェクト・コンバータの機能がリンカに吸収されており、その点を読み替えれば参考になるのでは。

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

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

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

In reply to NoMaY:

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

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

自分ならありますが?

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

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

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

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

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

すみません、所要でバタバタしていたので返信がかなり遅くなりました。

みなさんご返信ありがとうございました。
なぜ必要か、という事に関して一応回答しておきますと、

ブート領域を固定とするわけなので、フラッシュ領域だけを書き換えて、
ブート領域だけはずっと書きっ放しになるわけです。
（理屈上プログラムをRAM展開すれば書き換えをできるようにはしておきますが）

そこでROMに異常が生じた場合、フラッシュ側で異常が生じたのか、
ブート側で異常が生じたのか、切り分けをしたいと考えたわけですが、
フラッシュ側だけだと、どちらに異常が生じたか簡単に切り分けができない。

フラッシュ側を何度か書き直す手順を踏めば結果的にはわかるとは思いますが、
書き換えの手順上（誰かに作業をぶん投げるには）手間ですし、ブート側に自分で
CRCを埋め込むのはファイル管理上の観点からよろしくありません。
折角機能があるのだから何とかできないのかなと、考えて質問をしました。

出来なければ出来ないで致し方ないので、問題ありません。

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

リプライどうも有り難う御座います。以下の目的ということで私が思ったのは、ブート領域部分だけのCRCをブート領域のMOTにオブジェクトコンバータで埋め込み、かつ、フラッシュ領域部分だけのCRCをフラッシュ領域部分のMOTにオブジェクトコンバータで埋め込み、そうしておいて、ブート領域のプログラムで2つの領域それぞれに対し別々にCRCチェックを行い、それぞれで良否判定して2つともOKなら良しとする、というのでは駄目なのだろうか？ということでした。そういうやり方(2つの領域に対し別々にCRCチェックを行い2つともOKなら良しとする)のでは駄目なのでしょうか？

＞ そこでROMに異常が生じた場合、フラッシュ側で異常が生じたのか、 ブート側で異常が生じたのか、切り分けをしたいと考えたわけですが、 フラッシュ側だけだと、どちらに異常が生じたか簡単に切り分けができない。

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

ハードウェア高速CRC演算器が内蔵されていたことを思い出して、ハードウェアマニュアルを見てみたところ、合点がいくようになりました。演算範囲の先頭が0番地固定なのですね、、、

In reply to 豆大福:

豆大福 さん
ほや です。こんにちは。

諸々百も承知だと怒られそうですが…

オブジェクトコンバータはロードモジュールからバイナリを抜き出して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

皆さんご返信ありがとうございます。

高速CRC機能を使うのはその通りです。
ただ、他スレッドのCRC演算に関する質問については別機能の話なので関係ないですよ。

他、ご提案された内容については既に考慮、考案済みです。
(CC-RLの方はチェックしておりませんが、コンパイラは変えられませんので。)

なにより結局のところ、これは万が一のためのチェック機能の簡便化が本質であって、
そのために通常時の工数やミスの要因を増やすのは本末転倒ですから、
基本的にツール側で対応できないのであれば、それはそれで良いのです。

現状私案の中だと多分、問題が生じた場合、現在使用している書き換え用のWindows APLを
利用して内容を確認する形とします。

まぁ、元々はRL78の一般的な汎用G系列でスワップ領域が8KByte品の物があれば問題なかったのですが、
こちらもこちらで無いものは仕方ないので。