出力ファイル(.bin)のサイズを小さくしたい。


GAと申します。
表題の通り、RX660シリーズを使用したソフトを作成しております。
その際に、どうしても自力で解決出来ないことがあり、こちらに投稿させていただきました。
ただ、扱っているソフトが社外秘で直接ソースコードなどをお出しできない為、
質問自体が分かりにくくなってしまっております。大変申し訳ありません。
直接的な解決方法だけでなく、どんなアプローチで調べていけばよいか(自分ならこうする等)も
お教えいただけますと幸いです。


◎開発環境
・使用マイコン
R5F56609EDFP
・開発環境
 CS+


◎状況
現状のソフトをbin形式で出力させているのですが、
出力したbinファイルの容量が約4GByte程になってしまいます。
他の形式(.Hex)では、大きくて200KByteなので、どうにか容量を小さくしたいのですが、
どこをどう弄ればいいのかが分かりません。
この場合、どのようなアプローチでソフトを修正すればいいのでしょうか。
目的として、今回の出力したファイルを別のCPU(LinuxなどのOS)からアップデートファイルとして、
RX660シリーズに書き込み(アップデート)が出来るようになりたいです。
その際に、容量や通信速度の関係で、数百KByte程度(出来れば100kBye台)に納める必要があります。

いろいろと調べている際に、下記URLを見つけ、
<community-ja.renesas.com/.../cs-rx631>
状況として近いと気づきました。
つまり、ROMやRAMのセクションのほぼ全てをbinに詰め込んだ結果、4GByteまで膨れ上がっているのではないかと予想しております。
ただ、上記URLでの解決方法にあった、「FIXDVECT」(ベクタテーブルの配置セクション?)にあたるセクションがよくわからず、
単純にvcttbl.cの中身を#ifdefで読み込まないようにすると、Main関数を実行せず、メモリ番地の一番下を指し示してそこから動作しません。
(これは起動時に呼び出される処理が定義されなくなるのかなと考えています)

下記に現在のセクション設定のスクリーンショットを展開致します。

このソフトは、ROM上にあるプログラムをRAM上へ展開して動作させるような仕組みで考えております。
その為、セクションの設定の際に、ROM領域RAM領域のどちらにもプログラム領域を持っており、
これを起動時にROM領域からRAM領域へコピーする際のアドレス指定に使用しています。
理論上、ROM上にだけソフトが存在しており、RAM上には領域だけを指定できていれば、
書き込むソフトウェアとしては、ROM分だけで済むのではないかと考えているのですが、
そもそもこの認識自体が間違っているのでしょうか。

  • 「RXマイコン RAM 実行」で検索すると知りたい情報に辿り着けると思います。
    4GBって・・・設定がおかしいんでしょうね。

    プログラム実体自体を小さくしたいならビルドオプションで-Osにしてサイズを小さくする最適化をするといいと思います。

  • Shoji Yamamotoさん

    早速のご回答ありがとうございます。
    >「RXマイコン RAM 実行」で検索すると知りたい情報に辿り着けると思います。
    4GBって・・・設定がおかしいんでしょうね。
    →ありがとうございます。今一度調べ直してきます。

    >プログラム実体自体を小さくしたいならビルドオプションで-Osにしてサイズを小さくする最適化をするといいと思います。
    →こちらもありがとうございます。
     今のところ、実体はそこまで大きくないと考えております。
     というのも、このソフト自体がよりROMサイズの小さいH8Sシリーズからの移植なのですが、
     その際にはファイルサイズは問題になっていなかったそうなのです。
     (と言っても、そのソフト自体が別の会社様にて作られたものなので、厳密なことは分かりませんが…)
     今後の検討の際に参考にさせていただきます。

  • RXマイコン向けのバイナリをbin形式で扱うこと自体無理があるのではないでしょうか。

    binファイル→アドレス情報が無く0番地からのデータファイル…だと思うのですが。

    H8とかROMが0番地から始まっているマイコンであれば、bin形式で取り扱っても良いですが、RXは32ビットアドレスのマイコンで、FFFF_FFFFH付近にリセットベクタがあるので、どんなに単純なマシン語のプログラムを作っても必ず4GBになります。

    素直に、mot(モトローラS形式)か、hex(インテルhex形式)を最終的なアウトプットとすべきでしょう。

  • 補足します。H8との互換性のために、どうしても.bin形式で扱いたいのであれば、

    FFF0_0000H

    を基点にした、.binファイルを作る(サイズは1MBになります)と良いと思います。

    もっとサイズを小さくしたい場合は、プログラムの配置アドレスを後ろにずらしてください。

    例えば、セクション配置で、プログラムの先頭アドレス(RResetPRG)を、FFFF_0000Hに設定すると、

    FFFF_0000H ~ FFFF_FFFFH の64kBの.binファイルになります。プログラムサイズに合わせて先頭番地を調整してください。

    リセットベクタが最終番地にあるので、後ろはFFFF_FFFFH固定です。

    .binの作り方は色々考えられますが、単純にやるのであれば、motで出力してスクリプトでbinに変換するなどでしょうか。

  • 以下を参考にしてみてください。

    bin, mot, hex どの形式も指定ができます。

    一つから複数指定ができますので、特定の開始アドレスから終了アドレスまでを指定することができます。

    昔サイズの小さいROMを複数実装する場合に使う機能だったと思いますが、一つの指定も可能で指定範囲のbinも作成することができます。

    ただし、binファイル指定時は、4GBのファイルを生成してから調整するようですので、ビルド時の出力ファイル作成にmot生成に比べ少し時間がかかります。

    「分割出力ファイル」

    tool-support.renesas.com/.../bd_T_HexOutputOptions.html

    romからramに展開する考え方自体は特に問題はないです。

  • tfさん

    分かりやすいご回答ありがとうございます。

    >H8とかROMが0番地から始まっているマイコンであれば、bin形式で取り扱っても良いですが、
    RXは32ビットアドレスのマイコンで、FFFF_FFFFH付近にリセットベクタがあるので、
    どんなに単純なマシン語のプログラムを作っても必ず4GBになります。
    →確かに原理として、必ず4GBになってしまいますね。
     理解出来ました。

    >FFF0_0000Hを基点にした、.binファイルを作る(サイズは1MBになります)と良いと思います。
    >例えば、セクション配置で、プログラムの先頭アドレス(RResetPRG)を、FFFF_0000Hに設定すると、
    FFFF_0000H ~ FFFF_FFFFH の64kBの.binファイルになります。プログラムサイズに合わせて先頭番地を調整してください。
    リセットベクタが最終番地にあるので、後ろはFFFF_FFFFH固定です。
    →サイズ調整の考え方のご展開ありがとうございます。
     別の方の具体的な方法と合わせて、今回目標としているものが達成できそうです。
     ありがとうございます。

  • -donkey-さん

    具体的な方法のご展開ありがとうございます。
    また、romからramへの展開の考え方が間違っていないようで安心しました。

    >一つから複数指定ができますので、特定の開始アドレスから終了アドレスまでを指定することができます。
    昔サイズの小さいROMを複数実装する場合に使う機能だったと思いますが、一つの指定も可能で指定範囲のbinも作成することができます。
    ただし、binファイル指定時は、4GBのファイルを生成してから調整するようですので、
    ビルド時の出力ファイル作成にmot生成に比べ少し時間がかかります。
    →具体的な方法のご展開ありがとうございます。
     先ほど実際に分割出力を行ってみたところ、無事指定した領域のファイルを作り出すことが出来ました。
     あとは、別の方からご教授いただいた内容と合わせて、今回ソフトとして必要な部分だけを指定出来るような
     セクション設定や範囲の検討を行っていけそうです。
     ありがとうございます。

  • セクションの指定方法については、以下を参考にしてください。

    ROMに配置するプログラムをRAMに展開して実行するにはマッピング設定をしておく必要があります。

    ご指定のセクション設定ですが、ROMからRAMへマッピングする際のセクションはたいてい

    P → RP などのように プレフィックスとしてRを指定し(あくまで記憶で、CC-RXのリンカ―のルールだったような気がしますのでコンパイラマニュアルをご参照ください)、マッピング設定をすることで、RAM上で動作するようにリンク時にアドレスが調整されます。

    tool-support.renesas.com/.../bd_function_option12.html

    そしてRAM上のRPセクションにジャンプする前に、PセクションからRPセクションへすべての領域をコピーする処理が必要です。

    D、Cセクションなどの場合も値を参照する前にR領域にコピーする必要がある点は同様です。

    つまり、P、C、D領域対してRAMにセクションを追加し、マップ設定、プログラム内では、それぞれの領域をRAMセクションにコピーの順ですかね。

  • RX660 の場合、バイナリ形式では実際に約 4GiB なファイルが必要になったりするかもしれません。

    - OFSM の1領域が 0x120040 番地付近にある

    - OFSM の1領域が 0xFF7FFFE8 番地付近にある

    - コード領域が 0xFFF00000 番地にある (1MiB 品の場合)

    - 実機のブツに書き込む際には OFSM も書く必要がある

    ということで私も bin 形式ではなく mot 形式ないしは hex 形式にすることを推奨します。

    (ウチんところで使っているマイコンは RX660 ではありませんが)

    ウチでも CodeFlash の化けチェックの目的で CodeFlash 領域に、独自仕様の CRC を使っています。

    そのため、開発環境上で動かす計算ツールをビルドの際に起動して埋め込んでいます。

    この計算のために 4GiB もあるファイルを毎回ビルドされると時間かかって仕方ないのでちょっと工夫しています。

    - リンクした結果は abs ファイル、これは ELF32 形式である

    - abs ファイルから、計算のための CodeFlash 領域だけ抽出してバイナリにする( 1MiB のファイルとなる)

    - CRC 値を計算してそのバイナリファイルに埋め込む

    - abs ファイルから OFSM 部分だけ抽出する

    - CRC 埋め込み済み CodeFlash bin ファイルと OFSM を結合して mot/hex ファイルを生成する

  • cacao99さん

    ご回答ありがとうございます。
    >- OFSM の1領域が 0x120040 番地付近にある
    - OFSM の1領域が 0xFF7FFFE8 番地付近にある
    - 実機のブツに書き込む際には OFSM も書く必要がある
    →OFSMについて、データシート等を見て調べてみたのですが、
     今回、ソフトアップデートの為のバイナリファイルなので、恐らくアップデートの際には必要にならない認識です。
     一番最初にソフトを書き込む際と、OFSMに関わる設定を変更した際(ex.WDTの設定等)には
     この部分を書き込む必要があるのですが、
     ソフトアップデート程度であれば、元から書き込まれているOFSMで動作させられる認識です。
     
    >- リンクした結果は abs ファイル、これは ELF32 形式である
    - abs ファイルから、計算のための CodeFlash 領域だけ抽出してバイナリにする( 1MiB のファイルとなる)
    - CRC 値を計算してそのバイナリファイルに埋め込む
    - abs ファイルから OFSM 部分だけ抽出する
    - CRC 埋め込み済み CodeFlash bin ファイルと OFSM を結合して mot/hex ファイルを生成する
    →cacao99さんの方でされているやり方のご展開ありがとうございます。
     今後、プログラムに含まれない情報(CRCやバージョン情報等)を付加しなければならない可能性がありましたので、
     助かります。参考とさせていただきます。