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マイコン向けのバイナリをbin形式で扱うこと自体無理があるのではないでしょうか。
binファイル→アドレス情報が無く0番地からのデータファイル…だと思うのですが。
H8とかROMが0番地から始まっているマイコンであれば、bin形式で取り扱っても良いですが、RXは32ビットアドレスのマイコンで、FFFF_FFFFH付近にリセットベクタがあるので、どんなに単純なマシン語のプログラムを作っても必ず4GBになります…
RX660 の場合、バイナリ形式では実際に約 4GiB なファイルが必要になったりするかもしれません。
- OFSM の１領域が 0x120040 番地付近にある
- OFSM の１領域が 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 の１領域が 0x120040 番地付近にある- OFSM の１領域が 0xFF7FFFE8 番地付近にある- 実機のブツに書き込む際には OFSM も書く必要がある→OFSMについて、データシート等を見て調べてみたのですが、 今回、ソフトアップデートの為のバイナリファイルなので、恐らくアップデートの際には必要にならない認識です。 一番最初にソフトを書き込む際と、OFSMに関わる設定を変更した際(ex.WDTの設定等)には この部分を書き込む必要があるのですが、 ソフトアップデート程度であれば、元から書き込まれているOFSMで動作させられる認識です。 >- リンクした結果は abs ファイル、これは ELF32 形式である- abs ファイルから、計算のための CodeFlash 領域だけ抽出してバイナリにする（ 1MiB のファイルとなる）- CRC 値を計算してそのバイナリファイルに埋め込む- abs ファイルから OFSM 部分だけ抽出する- CRC 埋め込み済み CodeFlash bin ファイルと OFSM を結合して mot/hex ファイルを生成する→cacao99さんの方でされているやり方のご展開ありがとうございます。 今後、プログラムに含まれない情報(CRCやバージョン情報等)を付加しなければならない可能性がありましたので、 助かります。参考とさせていただきます。
selfupdate できるソフトウエアと通信回路が既に準備されていればオンボード更新の際に改めて OFSM を書く必要はありません（OFSM 内容に変更があれば別）なので OFSM を含まないバイナリだけあれば十分です。とはいうものの生産の際にブランクマイコンに書き込むためには OFSM ありな mot/hex 形式が必要ですし、開発環境で生成するj実行形式ファイルは当然ブランクマイコンに書き込めなきゃ意味がないので以下略。
GNU binutils の中に objcopy というツールかあります。これを使えば ELF32 形式 abs ファイルから今必要な部分だけ抽出して mot/hex にしたり binary にしたり逆変換できたりします。 Windows 向けのコンパイル済み binutils は cygwin あたりから持ってくると楽できそう。 mot 形式のファイルをくっつける際には S0 レコードや S9 レコードが邪魔で、削除には sed があると Good 。やはり cygwin に入っています。ポストビルド用の Makefile を作って make する（やはり cygwin ）だけですし、一度整備してしまえばいくらでも流用できたりしますね。
追加の情報ありがとうございます。
>elfupdate できるソフトウエアと通信回路が既に準備されていればオンボード更新の際に改めて OFSM を書く必要はありません（OFSM 内容に変更があれば別）なので OFSM を含まないバイナリだけあれば十分です。→こちらご確認いただきありがとうございます。自分の認識で問題なさそうで安心しました。
>GNU binutils の中に objcopy というツールかあります。これを使えば ELF32 形式 abs ファイルから今必要な部分だけ抽出して mot/hex にしたり binary にしたり逆変換できたりします。→こちら、情報のご展開ありがとうございます。cygwinのmakeは過去に一度使ったことがありましたので、何となくは知っていましたが、 objcopyとsedに関しては、初めて知りました。自分でも調べてみます。