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

使用デバイス:RL78/G13,G14

開発環境:CA78K0R

プログラムコードの領域をブート、フラッシュの2領域に分割して開発を行います。

ブート領域はスワップ機能を使わず、16KByte固定として残りをフラッシュ領域に割り当てる形としたのですが、

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

多分hexファイルへの埋め込みだけで、ロードモジュールに反映されていないのが原因とは思いますが、

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

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

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

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

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

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

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

    フラッシュ側はブート側のロードモジュールを読み込んで作りますから、
    ロードモジュールの引き継ぎデータに含まれていないのではないか、と判断したという事です。
    なお、デバッガで確認しても意味はないので、その点は見ていません。
  • ツールの設定はどうされてますか?
    あと、hex ファイルのフォーマットに何を使用されてるのかわかりませんが例えばインテルhexは後ろのレコードで前のレコードの値を上書きできる動作だったと思います。目視確認に絶対の自信でもない限りは

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

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

    >決めつけは危険と思います。
    必要なのはデバッグ時ではなく、hexファイルの出力結果ですので。
    そもそも今回のCRC演算は仕様上、通常のデバッグ時はエラーになりますし。
  • すみません、上の書き込みの「大口」というのは私です。
  • 結局どうされてるのかサッパリわかりませんでしたが、ルネサスのFAQにCC-RLで2つのエリアに対してCRCを設定する方法が掲載されているので参照されてはいかがかと思います。
    CC-RLはCA78K0Rのオブジェクト・コンバータの機能がリンカに吸収されており、その点を読み替えれば参考になるのでは。
  • 豆大福さん、こんにちは。NoMaYと申します。

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

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

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

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

    自分ならありますが?

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

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

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

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

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

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

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

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

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

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

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