こんにちは。NoMaYです。今首を傾げているのですが、RDP v1.20にはr_bsp v5.20が含まれていますので、それが使用されることを期待したのですが、実際は掲題の通りになります。ちょっと意外でした、、、(スマートコンフィグレータウィンドウのコンポーネントタブ上でr_bsp v5.20へと変更することは出来ましたので、恐らくRDP v1.20のインストールミスでは無いと思われます、、、)ちなみに、プロジェクトの生成では、コンパイラはCC-RX V3.01、デバイスはR5F565NEDxFP、に設定して試しました。
こんにちは。NoMaYです。同様にGNURXプロジェクトではr_bsp v5.20ではなくてr_bsp 4.0aが使用されてしまいます。r_bsp v5.20へと変更することは出来ますが、リンカスクリプトがv5.20対応では無いような気がしますし、ベクタテーブルの扱いもv5.20対応では無いような気がします。(ビルドしてみると、以下のエラーになってビルド出来ません、、、)それで思ったのですが、今現在のところ(特にGNURXプロジェクトに於いては)、RDP v1.20はAmazon FreeRTOSプロジェクト向け、という位置付け/状況なのかも知れません。(特にGNURXプロジェクトに於いては、ビルドするにはGNURX版Amazon FreeRTOSプロジェクトから幾つか小細工を持って来る必要がある、ということになります、、、)
Building target: TestGNURX.elf''Invoking Linker'rx-elf-gcc @"TestGNURX.elf.in"c:/renesas/gcc/redhat/gnurx-elf/4.8.4.201902-sp1/rx-elf/rx-elf/bin/../lib/gcc/rx-elf/4.8.4.201902-GNURX/../../../../rx-elf/bin/ld.exe: section .ofs7 loaded at [fe7f5d70,fe7f5d73] overlaps section .ofs6 loaded at [fe7f5d64,fe7f5d73]./src/smc_gen/r_bsp/mcu/all/resetprg.o: In function `PowerON_Reset_PC_Prg':C:\Renesas\RX\TB\workspace_e2v750\TestGNURX\HardwareDebug/../src/smc_gen/r_bsp/mcu/all/resetprg.c:187: undefined reference to `_exvectors_start'./src/smc_gen/general/r_cg_vector_table.o:(.rvectors+0x1ac): undefined reference to `_group_bl2_handler_isr'./src/smc_gen/general/r_cg_vector_table.o:(.rvectors+0x1b8): undefined reference to `_group_bl0_handler_isr'./src/smc_gen/general/r_cg_vector_table.o:(.rvectors+0x1bc): undefined reference to `_group_bl1_handler_isr'./src/smc_gen/general/r_cg_vector_table.o:(.rvectors+0x1c0): undefined reference to `_group_al0_handler_isr'./src/smc_gen/general/r_cg_vector_table.o:(.rvectors+0x1c4): undefined reference to `_group_al1_handler_isr'
こんにちは。NoMaYです。CS+(V8.02.00)＋スマートコンフィグレータ(V2.2.0)でr_bsp v5.20を使用すると、3種類のコンパイラ向けのそれぞれのiodefine.hのフォルダのパスが、3つともインクルードパスに含まれてしまいます。(下記の画面コピーを参照) CS+では、今のところ、まだiodefine.hを#include "iodefine.h"と書くことが出来ますので、これにはちょっと注意が必要ですね。(対して、e2 studioでは、iodefine.hのフォルダのパスをインクルードパスに含めることが出来ない(含めようとしてもコード生成時に強制的に除去される)ので書けなくなっていて、代わりに#include "platform.h"と書くことになっていますね。)対処としては、順番を入れ替えて(デフォルトは、IAR C/C++コンパイラ向け→GNURX向け→CC-RX向け、の順)、CC-RX向けのiodefine.hのフォルダのパスが最初になるようにすることかと思います。(なお、他のコンパイラ向けのiodefine.hのフォルダのパスを削除しても、CS+とスマートコンフィグレータの操作手順次第では、いつのまにか復活してしまうことがあります。)もっとも、今のところ、IAR C/C++コンパイラ向けのiodefine.hはCC-RXで使用しても正しく動作するように作成されていますので、ひとまずデフォルトの順番でも大丈夫なようです。以下、画面コピーです。3種類のコンパイラ向けのそれぞれのiodefine.hのフォルダのパスが3つともインクルードパスに含まれる対処としては順番を入れ替えてCC-RX向けのiodefine.hのフォルダのパスが最初になるようにする他のコンパイラ向けのiodefine.hのフォルダのパスを削除しても操作手順次第では復活してしまうことがあるちなみに、r_bsp v5.20内では、以下のように記述されていますので、インクルードパスの順番には影響されません。(さらには、インクルードパスにiodefine.hのフォルダのパスが含まれていなくても構いません。その代わり、r_bspのフォルダのパスが必要になります。)src/smc_gen/r_bsp/board/generic_rx65n/r_bsp.h
#if defined(__CCRX__)#include "mcu/rx65n/register_access/ccrx/iodefine.h"#elif defined(__GNUC__)#include "mcu/rx65n/register_access/gnuc/iodefine.h"#elif defined(__ICCRX__)#include "mcu/rx65n/register_access/iccrx/iodefine.h"#endif /* defined(__CCRX__), defined(__GNUC__), defined(__ICCRX__) */
それから、今のところ、IAR C/C++コンパイラ向けのiodefine.hは以下のように記述されていました。src/smc_gen/r_bsp/mcu/rx65n/register_access/iccrx/iodefine.h
略(コメント)#ifndef __RX65NIODEFINE_HEADER__#define __RX65NIODEFINE_HEADER__#ifdef __IAR_SYSTEMS_ICC__#pragma language=save#pragma language=extended#ifndef _SYSTEM_BUILD#pragma system_include#endif#endif#ifdef __IAR_SYSTEMS_ICC__#define __evenaccess#else#define __sfr#endif略(CC-RX向けのiodefine.hと同じ内容)#define BSC (*(volatile struct st_bsc __sfr __evenaccess *)0x81300)#define CAC (*(volatile struct st_cac __sfr __evenaccess *)0x8B000)略#define WDT (*(volatile struct st_wdt __sfr __evenaccess *)0x88020)#define FLASHCONST (*(volatile struct st_flashconst __sfr __evenaccess *)0xFE7F7D90)#define TEMPSCONST (*(volatile struct st_tempsconst __sfr __evenaccess *)0xFE7F7D7C)略(CC-RX向けのiodefine.hと同じ内容)#ifdef __IAR_SYSTEMS_ICC__#pragma bitfields=reversed#else#pragma bit_order left (←CC-RX向けのiodefine.hと同じ)#endif#ifndef __IAR_SYSTEMS_ICC__#pragma unpack (←CC-RX向けのiodefine.hと同じ)#endif略(CC-RX向けのiodefine.hと同じ内容)#ifdef __IAR_SYSTEMS_ICC__#pragma bitfields=default#pragma language=restore#else#pragma bit_order (←CC-RX向けのiodefine.hと同じ)#endif#ifndef __IAR_SYSTEMS_ICC__#pragma packoption (←CC-RX向けのiodefine.hと同じ)#endif#endif
こんにちは。NoMaYです。掲題の件、原因はe2 studioの[ヘルプ]→[更新の検査]/[新規ソフトウェアのインストール]からでは正しく最新版へアップデートされない(ケースがある?)、ということでした。(CS+ではアップデートマネージャでアップデートし続けて問題無かったので油断していました。)setup_e2_studio_7_5_0.exeで新規インストールしてみたら問題無くなりました。また、GNURXプロジェクトの問題も無くなりました。実は、コード生成コンポーネントのバージョンがCS+ V8.02.00とe2 studio v7.5.0で異なることに首を傾げ始めていたり、e2 studio v7.5.0で搭載された筈の[インポート]→インポートダイアログ→[Renesas GitHub Amazon FreeRTOS Project]が見当たらなくて首を傾げ始めていたり、していたのですが、こちらも解消されました。トホホ、、、