Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

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

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

開発環境:CA78K0R

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

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

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

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

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

  • In reply to 豆大福:

    > 基本的にツール側で対応できないのであれば、それはそれで良いのです。

    対応できると思いますが、当人ができなくて良いという程度の問題であったのであればそもそもの話として他人に相談などされないほうが良かったですね。
  • In reply to fujita nozomu:

    > 対応できると思いますが、

    以下、自己レス。

    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 の値は設定されていることが確認でき、問題なさげであったことをご報告しておきます。

  • 正直どう回答してよいものかと考えておりましたが、
    このまま放置するのも掲示板の検索履歴上問題かと思いますので、
    ご返信いたします。

    お手数をおかけして大変申し訳ありませんが、記載された内容は
    質問の回答にはなっておりません。boot.hexとflash.hxb、または分割を
    やめてをflash.hexでもかまいませんが、比較検索ソフトで確認して
    みてください。flash.hxb/.hexに足りないものがありませんか?

    問題となっているのは、boot.hexの演算結果がflash.hxb、またはflash.hex
    に反映されていないため、flash.hexを書き込むことを前提にそのまま機能を
    入れ込むと、高速CRC演算によるフラッシュの状態チェックがブート側
    (入れ込み方次第では両方とも無効になりますが)で正常に行えないことです。

    元々の意図はオブジェクトコンバータの仕様確認と、ツール上の機能に関する
    質問のつもりでしたが、最初の記載方法が悪かった上に、
    主に業務運用で使用するソフトウェア構造上の設計が絡む機能をこの掲示板で
    質問するのは適切ではなかったと思いますので、今後このような質問は控えます。

    大変申し訳ありませんでした。なお、これ以上の返信はいたしません。
  • In reply to 豆大福:

    豆大福さんのやりたい事は分かりました。

    ツールの設計思想として、フラッシュ丸ごとのCRCが計算できれば、OKということで
    bootのCRCと丸ごとのCRCの2段階でCRCを取ることは考えていないようですね。

    CS+でやるならアセンブラでBOOT部のCRCをdb命令で埋め込めばlmfにも反映されるようです。

    BOOT部はそうそう修正は入らないと思いますから、通常の手順でHEXにCRCを付加する設定をして、オブジェクトコンバータで出力されたCRCの結果をアセンブラで定義しなおせば全体コンパイル時にBOOTのCRCも取り込まれます。(更新時はCRCの再設定を忘れずに)

    ↓CRCをデバッグする場合の設定(CRCが埋め込まれたHEXを追加で読み込めば、CRCがメモリにロードされます。)

  • In reply to 豆大福:

    > boot.hexとflash.hxb、または分割を
    > やめてをflash.hexでもかまいませんが、比較検索ソフトで確認して
    > みてください。flash.hxb/.hexに足りないものがありませんか?

    アップロード公開したアーカイブ中の HEX ファイルの内容を目視で確認してみましたが

    boot.hex: 00000~01FFF ベクタテーブル、オプションバイト、オンチップデバッグセキュリティID設定領域、ブート部コード、ブート部データ、ブート部CRC
    flash.hxf: 02000~0FFFF フラッシュ部コード、フラッシュ部データ、フラッシュ部CRC

    となっており、足りないものは見当たりませんでした。
    「~が足りない」ということであれば具体的に指摘されるべきことと思います。他人の労力を無駄にさせるだけであり正直どうかという感じですね。
  • In reply to Kirin:

    > ツールの設計思想として、フラッシュ丸ごとのCRCが計算できれば、OKということで
    bootのCRCと丸ごとのCRCの2段階でCRCを取ることは考えていないようですね。

    > BOOT部はそうそう修正は入らないと思いますから、通常の手順でHEXにCRCを付加する設定をして、オブジェクトコンバータで出力されたCRCの結果をアセンブラで定義しなおせば全体コンパイル時にBOOTのCRCも取り込まれます。(更新時はCRCの再設定を忘れずに)

    ブート部 1.00 と フラッシュ部 1.00 を最初にリリースしたとして、後にブート部の内容は 1.00 から変えずにフラッシュ部のみを更新するとした場合、フラッシュ部の CRC にブート部の内容も含まれるとするとビルドの際にはブート部 1.00 の内容を保証する必要が出てくるので労力的に良い方法ではないでしょう。
    フラッシュ部を更新する際にコンパイラのバージョンアップだとか(CA78K0R では可能性低そうですが)、コンパイルオプションの変更だとかに気を遣うこととなります。コンパイラに関係なくブート部 1.00 の内容が常に再現できるようアセンブラソースに差し替えることも可能ではありますが、要らない作業が増えるという点では同じです。フラッシュ部の CRC にはブート部の内容は含めるべきではないと思います。
  • In reply to fujita nozomu:

    Fujitaさん
    私もそう思います。
    boot.hexを書いたあとにブロック書き込みでflash.hxfを追加するのは一手間ですけど。

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page