スマートコンフィグレータのコード生成によるバグの発生

スマートコンフィグレータにてコード生成を行うと、生成されたコードがバグだらけになります。
画像のトランスミットFIFOデータ数トリガを0→1に変更したので、コード生成を行いました。

そうするとソースコードにバツ印が付き、プログラム内で下記のようなエラーメッセージが出ます。

   

原因わかりますでしょうか。コンポーネントの設定を変えたタイミングで何度かコード生成していますが、今回の症状が出たのは初めてです。
現在のコンポーネントのバージョンは下記画像です。

使用しているのはe2studioの2023-7、CCRX-V3.00 です。

下記URLを参考にファイルサイズを大きくしましたが、解決していません。

ja-support.renesas.com/.../17797612

そもそも、スマートコンフィグレータでコンポーネントの設定を変えただけで、ファイルサイズがオーバーすること等あるのでしょうか。

何かわかる方いればよろしくお願いします。

  • > 下記URLを参考にファイルサイズを大きくしましたが、解決していません。
    いくつを設定しているでしょう?もっと大きくしてみては?

    Skip xx larger than ... の設定は、多分本来は索引付け(indexing)の段階で巨大なファイル(ヘッダファイル含む)があった時、ただそれだけのために他のファイルの索引付けがされないままになってしまう現象を回避するために設けられたのだろうと推察しますが、
    実際はプロジェクトの規模が大きくなった時(ファイルサイズでなくファイル数が増えた時)にも効いてくるようです。
    今回の現象もこれが関係しているような気がします。

    ヒープサイズを見る機能を有効にして、ガベージコレクションをやりながら動かしてみるとか。
    参考: Eclipseの起動時のメモリ量(Xms)と最大のメモリ量(Xmx)の確認方法
    https://itsakura.com/eclipse-xms-xmx

  • これ、ビルドが通るならスマートコンフィギュレータのバグではないです。

    EclipseベースのIDEではよくあることで参照名のインデックスを作成するときメモリ制限を超えると起こります。制限を増やすか気にしない。もしくはコード生成後に再度インデックスの再構築を実行するといいです。生成前のインデックスが残っていて新規に作ったものでインデックスが増えてメモリを使い果たした可能性もあります。私はクリーンアップしてプロジェクトを一度閉じて、再度開いた後にインデックスを再構築したりします。

  • ほや様
    12MBと25MBで設定しています。

    ヒープサイズの確認機能を教えていただきありがとうございます。まだ半分も言っていないので余裕はありそうです。
    昨日、散々インデクサーの再構築などしても治らなかったのですが、今朝起動すると症状が消えていました。
    まったくもって原因不明ですが、今後同じ現象が起きた場合にはヒープサイズの確認と、ファイルサイズの変更で対応しようと思います。ご回答ありがとうございました。

  • Yamamoto様
    ビルドしてもエラーもワーニングも起きず、挙句デバッグも普通に出来ていました。インデクサーの再ビルドでも治らなかったので、原因不明でした。EclipseベースのIDEではよくあることなのですね。何か理由があって生成前のインデックスが残っていしまい、結果としてすべてのインデックスが2重になっていた可能性がありますね。昨日はずっとプロジェクト立ち上げたままで治せるか試していましたが、今朝プロジェクトを立ち上げると、エラーがすべて消えていました。ご指摘の通り、「一度プロジェクトを閉じる」がもっとも手っ取り早い解決方法だったかもしれません。ご回答ありがとうございました。

    ちなみにですが、Eclioseで起きる問題が確認できる日本のコミュニティなどあるのでしょうか。e2studioで解決策を考えるよりもEclipseで検索したほうが良いと聞いたことがあるのですが.....。何か知っているものがあれば教えていただくことは可能でしょうか。

  • まず一点、スマートコンフュギュレータの生成コード自体はバグコードを吐き出さないですが、仕様として「ダメ」な点(あくまで私の主観です)。例えば顕著なのがタイマー系のコンポーネントの生成コードの生成ルールの仕様で生成したコードのマクロ宣言に値そのものを含んだマクロ名が生成されるという謎な仕様を持っている点です。具体的には三相モーター用のコンポーネントの生成コードでTCNT値が生成されますが、ツールの使用者(主観としての私)としてはコンポーネント設定で与えた周期設定がTCNT_VALUE_みたいなマクロ名でそれが値として参照できることを期待するのになぜか、_XXXX_3TCNT_VALUE (3はMTU3なのでまぁ仕方なしでしょうけど)というふうにXXXXに設定値が書かれたマクロ名で実態はXXXXそのものです。つまり0x00F0Uを設定したら


    #define _00F0_3TCNT_VALUE (0x00F0U) /* MTU3.TCNT value */

    というのが生成されるわけです。

    なので値を変更してコード生成すると参照名としてのマクロがどんどん追加されるんでインデックス生成用のメモリがどんどんなくなるというわけです。一度クリーンアップしてインデックスを再構築する必要があるというのはこれが主たる原因です。

    ほんとこの謎仕様、そろそろこの生成方法を考えた人は責任を感じてほしい。これを「ヨシ!」としている人はいたら私と議論しましょう。こんな生成なら自分で数値を直埋めします。

    Index作成で完了しなかったり完了しなくて参照できなくてエラーになるのはJavaの頃から(EclipseはもともとJavaようIDEとして開発された後CDTというプラグインを入れてC・C++開発に対応できるようになっています)ですので、まぁ、そういうものなんです。e2studioはそれにルネサスマイコンに特化したプラグインを一式揃えたIDEなので警告などが出た時、何が起因しているか?って切り分けは初学者にはちょっと難しいかもです。

  • Yamamoto様

    クリーンアップというのは「プロジェクトをクリーンにする」というメニュー内の操作の事でしょうか。
    設定値がかかれたマクロが毎回生成されて蓄積されるのは本当に謎仕様ですね。値だけ変えれば済むはずのマクロの良さがなくなっていますね。メモリがどんどんなくなる原因が分かりました。

    まさに問題の切り分けが壁として立ちはだかっていますね。これはもう片っ端から解決してなれるしかないですね。

  • インデックスがやり直しになるのはコード生成時にフォルダごとファイルが作り直されるからだと思います。
    余計なプロジェクトがオープンされていると重くなると思います。インデックスはプロジェクトごとに持っているので。
    余分なビューを閉じておくとか、eclipseを軽くするための一般的な対策は知っておくと良いです。

  • ほや様

    コード生成時に元々生成済みのファイルの差分だけ治ってくれると良いのですが、そういう事ではないのですね。

    eclipseを軽くするという対策について考えたことがなかったので、調べてみようと思います。

  • 遅い返信ですみません。鈴木と申します

    いろんなところからの要求に応じているうちに謎設定になってしまっています。

    今はレジスタに直値が入るようなオプションがあるので、ご利用ください

  • 鈴木様、試してみました。教えていただいたように設定変更して生成すると初期化APIは数値が直で出力されているのですが、そう言うことじゃないです。だめですね。要望の動作ではないです。残念です。

    これはモーター用のコンポーネントの出力例です

    #define _00F0_3TCNT_VALUE            (0x00F0U) /* MTU3.TCNT value */
    #define _00F0_TDDRA_VALUE            (0x00F0U) /* MTU.TDDRA value */

    #define  _0BB8_TCDRA_VALUE           (0x0BB8U)
    #define  _0BB8_TCDRB_VALUE           (0x0BB8U)
    #define _0BB8_TCDRA_VALUE            (0x0BB8U) /* MTU.TCDRA value */
    #define _0654_3TGRB_VALUE            (0x0654U) /* MTU3.TGRB value */
    #define _0654_4TGRA_VALUE            (0x0654U) /* MTU4.TGRA value */
    #define _0654_4TGRB_VALUE            (0x0654U) /* MTU4.TGRB value */
    #define _0CA8_SUM_VALUE              (0x0CA8U) /* Timer General Register (TGR) value */

    こういうのが出るのがダメだと言うの私の考えです。以下のような出力形式がいいと言うことです。

    #define _3TCNT_VALUE            (0x00F0U) /* MTU3.TCNT value */
    #define _TDDRA_VALUE            (0x00F0U) /* MTU.TDDRA value */

    #define  _TCDRA_VALUE           (0x0BB8U)
    #define  _TCDRB_VALUE           (0x0BB8U)
    #define _TCDRA_VALUE            (0x0BB8U) /* MTU.TCDRA value */
    #define _3TGRB_VALUE            (0x0654U) /* MTU3.TGRB value */
    #define _4TGRA_VALUE            (0x0654U) /* MTU4.TGRA value */
    #define _4TGRB_VALUE            (0x0654U) /* MTU4.TGRB value */
    #define _SUM_VALUE              (0x0CA8U) /* Timer General Register (TGR) value */

    なぜ現状の仕様はマクロ名に値が埋め込まれているような仕様にしたんでしょうか?と使うたびに不思議な気持ちになります。マクロとしての意味ないですよね。値参照したいというのにそれができないので別途、別ファイルを作成して設定値を定義する必要が出てきて生産性が低いです。ツール上の設定値変更と別途用意したファイルの定義値の連動を手動でするのはナンセンスです。