EtherNet/IP OpENer Sample Program xspi0 boot mode cant build

How Users can arbitrarily use ram (RAM 1.5MB or ATCM or BTCM)

It seems, Renesas simple example codes are mapped to BTCM, while they are small enough to fit on BTCM. As far I know, when you would like to change the program execution memory(RAM), you may need to work on linker script and startup code. So that you can execute your code on ATCM, SRAM, or SDRAM. 

You will find more details on RZ/N2L boot sequence in UM, Chapter "3.5 Operating Mode Descriptions". Also, there is a example code in Renesas website with the loader program and application program are separated.

For the EtherNetIp project, we still hope that you can help us modify it so that it can compile and run normally with xspi0.

I have read UM 3.5 and tested the project (Device Setup Guide for Flash boot). My understanding is that the booter project and Parameters for the loader are saved to the external flash, which will be copied to the TCM and run after startup, just like the user application.

But I still don't understand how to modify the ld file and start file. Looking forward to your reply

I only know how to define a single variable to the specified ram, such as char in_ccram_buffer[1024] __attribute__((section("ccmram"));

You can use Renesas example code "RZ/N2L Group Example of separating loader program and application program projects" as reference for your work and do the the rest/additional/require modifications either in startup/linker script yourself by following the RZ/N2L User's Manual. 

RZ/N2L has ARM Cortex-R52 core. So, if you simply search on internet, you will find many articles, pdfs, tutorials for ARM core to explain "How modify the ld or work with a linker script for GCC project, as well as IAR system project". 

Thanks !

By referring to the Device Setup Guide for Flash boot, I tested the use of parameter_generator.py to generate the merged loader. Then use device_setup.py to download the device setup program (.srec) to BTCM, and finally use device_setup.py to burn the merged loader bin file generated in step 1 to spi flash. We can see that the loader is running and the led is flashing correctly. But none of this is going to help fix how the EthernetIP project (running on xspi0) won't compile properly.

key is how to modify the ld file. I tried to modify the text to the system RAM area, but there were many other errors. I need your effective help.

Also, by testing the Device Setup Guide for Flash boot documentation, I was wondering if, instead of using two Python scripts to burn, I just created a quickstart project and chose xspi0 to boot, and finally burned it using e2studio, Will that work with a new blank mpu? Does setting xspi0 only through e2studio automatically generate parameters for the loader and burn them to spi flash along with the application? Does the RSK development board already contain the Parameter for the loader and loader? Is it possible to burn applications using e2studio and run properly if the MPUs are blank?

Hello,

"RZ/T2M and RZ/N2L Group Device Setup Guide for Flash boot":

Supports QSPI flash and NOR Flash as external flash and writes the user program to the external flash via SCI or USB. It is assumed that the example program(LED Blinky) to be built and it will run on BTCM. On the other hand the EtherNET/IP example is mapped to run on System RAM. You need to edit the *.ld file under the project directory to change the memory allocation. I think in that case you can also cross check(if needed) the startup code to be aligned with your *.ld file.

Please check the reference "RZ/N2L Group Example of separating loader program and application program projects" where *.ld is configured for flash's and all RAMs (ATCM, System SRAM, SDRAM).

In general I would answer YES to all of your questions.

However, at the end it is use case specific for a user application program, where(Flash) to be stored and where(RAM) that needs to run/execute. In that case, take care the the rest/additional/require modifications in startup/linker script by yourself.

hi Kazi，

i already test “Example of separating loader program and application program projects”，I understand the basic operation situation, but there are still some questions I do not understand, I need to consult。

• I understand the process

1.loader project startup use “g_bsp_loader_param” And I can see these parameters in the hex file，then，loader code Copy application program to ATCM from flash memory，Copy System RAM program to System RAM from flash memory，last jump app。

2.app project havenot header（g_bsp_loader_param），

but，void func_sram_data_init(void)（Initialize System RAM data with initial value.）

void func_sram_bss_init (void)（Clear the System RAM bss.）

I don't understand the functions of these two functions. I think these two functions can be removed, because ATCM and SRAM have been copied in loader project. ld file I can see that only functions and variables of func_ram. c file are defined in the sram area, but this does not affect that the copy has been completed in loader.

So I have three questions:

1.func_sram(); Where is it necessary to copy data and clear bss in the function?

2. Can you define all (.text*) (.data*) (.bss*) (COMMON) to the sram area instead of ATCM

3? Why is BTCM still used in the ld of the app project, for example, data 0x00104000: line116: AT (_mdata) {} > BTCM, line 152:.bss: {} > BTCM

/* Execute the program on System RAM. */
func_sram();

/* Define destination / source address pointer and block size for data with initial value.*/
 uint32_t * src_data_init = (uint32_t *) &_msystem_ram_data_start;
 uint32_t * dst_data_init = (uint32_t *) &_system_ram_data_start;
 uint32_t size_data_init = ((uint32_t) &_system_ram_data_end - (uint32_t) &_system_ram_data_start);

src_bss = (uint8_t *) &_system_ram_bss_start;
dst_bss = (uint8_t *) &_system_ram_bss_end;

Why does loader only copy a small part of ATCM and SRam, but not all of them? loader has copied, why do sram data and bss in app need to be copied again? I masked the copying process and found that sram_data variable in map was still in sram after compilation.

Hello Jerry,

Current "separating loader program and application program projects” is an initial version and sample project. In my perspective, as an initial version, it's covered all RAM types(ATCM, SRAM, SDRAM) in one loader project and that's makes the software structure little bit complicated to understand.

However, as far I know, Renesas is working on it and they will release next/updated version of "separating loader program and application program projects" soon. I hope those limitation will be eliminated in new version.

Hello Jerry,

Current "separating loader program and application program projects” is an initial version and sample project. In my perspective, as an initial version, it's covered all RAM types(ATCM, SRAM, SDRAM) in one loader project and that's makes the software structure little bit complicated to understand.

However, as far I know, Renesas is working on it and they will release next/updated version of "separating loader program and application program projects" soon. I hope those limitation will be eliminated in new version.