memory_regions.icf is not updating with flash_image start_address and few other parameters when generated by IAR EWARM.

Hello adithi ,

Thanks for reaching out Renesas Engineering Community.

The e2studio includes a tooling mechanism which the application project can use to pick up the bootloader project, the flash layout settings and a python command line for creating finally the signed application image. In IAR this tooling mechanism doesn't exist so you have to do some work manually to make it work.

Basically as soon as you add in Build settings of your application project in e2studio the .bld file of the bootloader it modifies the memory_regions.ld file automatically to include the information for the flash layout:

So in IAR as you mentioned you need to modify manually the necessary info for the flash layout in the memory_regions.icf file and modify it according your flash layout:

In order these settings won't be overwritten every time you build your project in IAR when using newer RASC versions than 5.2.0 there is a batch file which launches RASC and generated code every time you build your project and that's why you loose the modifications you make to the memory_regions.icf file. To prevent this batch file from running and generate code through RASC and loose your changes every time you build the project you should go to your project Options->Build Actions and remove this Pre-Built and Post-Build commands:

In my case I made tests with a bootloader project for EK-RA6M5 using overwrite only upgrade mode and I created in IAR a bootloader project using MCUboot and a blinky application project. I will also attach here the projects for your reference.

So as soon as I created my bootloader project in IAR using MCUboot and RASC , generated code and built my bootloader project I proceeded creating my application image blinky project with RASC again.

1.In my application project I modified the memory_regions.icf file to include the flash layout information by doing the steps mentioned above.

2. I built my application project.

3. Than I need to convert the output file generated to a .bin file. To do this I run this command in command line:

arm-none-eabi-objcopy.exe -O binary Debug\Exe\app_ra6m5_boot.out Debug\Exe\app_ra6m5_boot.out.bin

4. The binary file now also contains the option setting registers so to remove these from the binary file I cropped the generated binary by using srec_cat.exe. So I run this command:

srec_cat.exe Debug\Exe\app_ra6m5_boot.out.bin -binary -crop 0 0x1FB00 -o Debug\Exe\app_ra6m5_boot.out.bin.cropped -binary

And by this way I created a cropped binary finally that doesn't include the option setting registers.

5.Then I signed this cropped binary file by running this python script from the bootloader project in command line:

python ..\mcuboot_ra6m5\ra\mcu-tools\MCUboot\scripts\imgtool.py sign --key ..\mcuboot_ra6m5\ra\mcu-tools\MCUboot\root-ec-p256.pem --version 1.0 --header-size 0x200 --align 128 --max-align 128 --slot-size 0x20000 --max-sectors 4 --overwrite-only --confirm --pad-header Debug\Exe\app_ra6m5_boot.out.bin.cropped Debug\Exe\app_ra6m5_boot.out.bin.cropped.signed

6. Then I needed to write the application image to the area of internal flash that I have declared as primary slot in my bootloader layout.

So I loaded into the area where the primary slot starts and I verified that this area includes the application image:

And that the rest areas like from example from where bootloader starts are blank:

And this it when I launched a debug session in IAR in my bootloader project the bootloader was able to jump to my application image and I could see the leds on EK-RA6M5 blinking.

Find the projects in this link for your reference. 

Your files can be downloaded at:
download.transfer.hennge.com/jK0A_abcIZaqq3

Expiration date: 2025-04-17 14:24 (UTC)

Your files can be accessed with the following password:
6dx1nV1p*8gV

Best Regards,

IK

Hello adithi ,

I saw that you downloaded the projects. Is there any feedback you would like to share?

Thanks and Regards,

IK

Hii,

I read those bytes and unfortunately they are all 0s. 

So there is nothing I can do to recover it?

Thanks and regards,

Adithi K

Hii,

Also, I wanted to know if my understanding of the whole MCUBoot process on RASC and IAR as I mentioned before correct, so that I could implement the same on RA6E1 board as you have shown?

Thanks and regards,

Adithi K

Hello adithi ,

Yes I am sorry, you have permanently locked your board and unfortunately as mentioned before in my previous answer in this case the board cannot be recovered.

Regarding the process for the bootloader and the application image in IAR with RASC.

I created my bootloader project using the MCUboot stack and defined my flash layout in MCUboot stack properties.

Than I also created my application project. In my application project I modified the memory_regions.icf

so that it will include the flash layout information.

1. Than I built my application project. As soon as I build it I take the output file .out generated into Debug/Exe folder of my project and I converted it to binary file using command:

arm-none-eabi-objcopy.exe -O binary Debug\Exe\app_ra6m5_boot.out Debug\Exe\app_ra6m5_boot.out.bin

2. Later by using srec_cat.exe  I cropped the binary to produce a new cropped binary:

srec_cat.exe Debug\Exe\app_ra6m5_boot.out.bin -binary -crop 0 0x1FB00 -o Debug\Exe\app_ra6m5_boot.out.bin.cropped -binary

3. And than I signed the application image running the python scripts in the bootloader project:

python ..\mcuboot_ra6m5\ra\mcu-tools\MCUboot\scripts\imgtool.py sign --key ..\mcuboot_ra6m5\ra\mcu-tools\MCUboot\root-ec-p256.pem --version 1.0 --header-size 0x200 --align 128 --max-align 128 --slot-size 0x20000 --max-sectors 4 --overwrite-only --confirm --pad-header Debug\Exe\app_ra6m5_boot.out.bin.cropped Debug\Exe\app_ra6m5_boot.out.bin.cropped.signed

4. Later I load the application image in the address where my primary slot is.

5. At the  end I launch a debug session through IAR and download also in the board the bootloader project and this is it, the bootloader than jumps to the application image and I see my application image running (as it is a blinky project and I see the leds on EK-RA6M5 blinking).

Thanks and Regards,

IK

Hii,

Thank you. Can I also use this approach? I changed the output type to .bin 

and removed the option setting register setting from .hex file.

does removing these bytes cause any trouble?

I had one more question: If I only wanted to sign and verify using keys generated by me on e2studio and then flash using jflash lite, is it okay to first flash the bootloader (.bin file with its option settings) followed by flashing the application(.bin file without option settings - here hex2bin conversion is required) to the appropriate address on the board? Because I think in the end I will only be using jflash application with bootloader and application for production. Hence the question.

Thanks and regards,

Adithi K

Hii IK,

I checked the .bin file that was generated for my bootloader. there are so many 0s written here. I had used the same .bin file to write into my board. I also realised that, wherever my .hex file had '-' filled, my .bin file has 0 filled in the exact address. 

this is my .bin:

this is my .hex:

I think the same 0 value is written in my board. This problem arises only when i generate code in  RASC and IAR. How are u able to read 'F' in the same address from the .hex file that i had shared earlier?

I am awaiting your response.

Thanks and regards,

Adithi K

Hello adithi ,

I simple opened them with a hex viewer.

How did you generated your bootloader  binary file.

Another thing you could do so that you will be sure that the option setting memory area won't be programmed when you flash your bootloader.

You can use for example any tool like Renesas Flash programmer and select not to program this area:

Deselect this area so you don't program option setting area or crop it to do not include these regions.

Thanks and Regards,

IK

Hii IK,

Sure I will not check the option setting area while dumping. I generated .bin from IAR by changing this setting:

Thanks and regards,

Adithi K

Yeah I also converted the .hex of bootloader you provided to bin and I was able to see the zeros in these areas:

Converted bin from hex:

You can either crop the bootloader binary to do not include the option setting memory area addresses.

Or you can select to do not program in RFP the config area.

For me the better option would be to crop the file.

Thanks and Regards,

IK

Hi,

I shorted the MCUBoot pin on EK-RA6M5 board and connected to J11. I got the below error codes on RFP when i tried to initialize/program it:

Is there any thing I can do?

Thanks and regards,

Adithi K

Hi adithi ,

So as far I can understand you used EK-RA6M5 and you placed the MCU to USB boot mode by driving the MD/P201 pin to low. And in your connections you selected COM port and 2-wire UART interface.

Is that correct?

Well the specific error if you will check the status codes: on this doc:www.renesas.com/.../standard-boot-firmware-ra-family-mcus-based-arm-cortex-m33

Is indicating that you have enabled some security protection and that you are trying to access areas for which security protection has been enabled.

Have you tried to flash again the bin of the bootloader on EK-RA6M5? 

Is it possible that you have also written zeros to the areas I mentioned in my comments above?

Thanks and Regards,

IK

Hi adithi ,

So as far I can understand you used EK-RA6M5 and you placed the MCU to USB boot mode by driving the MD/P201 pin to low. And in your connections you selected COM port and 2-wire UART interface.

Is that correct?

Well the specific error if you will check the status codes: on this doc:www.renesas.com/.../standard-boot-firmware-ra-family-mcus-based-arm-cortex-m33

Is indicating that you have enabled some security protection and that you are trying to access areas for which security protection has been enabled.

Have you tried to flash again the bin of the bootloader on EK-RA6M5? 

Is it possible that you have also written zeros to the areas I mentioned in my comments above?

Thanks and Regards,

IK

hey,

Thanks for the response. Yes I have observed that 0s are written to the areas that you had specified earlier.

I have an additional question: 

Can we control transfer of image from secondary slot to primary slot through software? What if I want to do transfer at scheduled time?

Can I know how system reset interrupt is initiated as soon as image is transferred from secondary to primary?  How is it handled in this blinky project?

I understand that the bootloader checks if magic number is present at the end of image in secondary slot. only if it is present it verifies the secondary image.

Thanks and regards,

Adithi K

Hello adithi ,

What you are  describing is already implemented by the bootloader code and the code of MCUboot which has been ported in FSP and can be easily used.

Specifically as you mentioned the mcuboot is responsible for validating and authenticating the new image stored in the secondary slot and later depending the mode you have selected specifically in Overwrite and Swap upgrade mode after successful authentication of the image in secondary slot it transfers the new image from secondary slot to primary slot which is the active slot in these two modes mentioned and than runs and boots the application.

For more information about the available upgrade modes and how they work please check this document:

Section 1.2.2.

https://www.renesas.com/en/document/apn/ra6-basic-secure-bootloader-using-mcuboot-and-internal-code-flash?r=1168086

Thanks and Regards,

IK

Hii, 

May I know what is calling the Reset_Handler() function in the code? I am not able to find out what is resetting the micro controller. I want to know what is resetting the MCU when I transfer the image onto the bootloader so that right after reset, the code enters main.c and boots the image.

Thanks and regards,

Adithi K

Hello adithi ,

Well typically for an MCU the reset handler is the first piece of code that is executed after system reset.

It includes all the C start-up code for proper initialization of your system and it sets up important things like memory configurations for heap and stack memories, it also initializes the stack pointer and it sets up the clocks and many other things that are important for the system initialization before executing the main code of your application.

Such kind of information you can find inside the SystemInit() function where in the code you can see such initializations being done.

Thanks and Regards,

IK

hey,

I was working on my ra6e1 board and i got a segger software update and after updating it, i am unable to erase flash or program to it. if i launch a debug session on iar the PC points to 0xeffffffe. if i force program the pc to point to 0x0 or 0x4 where i have my reset handler it will go there, but when i play or click on step into, pc will go to 0xeffffffe. 

when i try to erase the flash on e2studio, i get the below error:

I read the memory of the device using JMem and the memory is as below and option setting registers part of memory also seems fine. i have attached the jlink commander response also inside the zip folder.

3652.memory_ra6e1.zip

when i use rfp to initialise i am getting the below error:

Please please let me know how i can resolve this- this is the only board i have.

Thanks and regards,

Adithi K

Hello adithi ,

Well if you flashed the FW you attached here I can see in the option setting memory that you have written random data and in some addresses you wrote zeros , which means again that you have enabled protection of blocks in code flash.

The specific error code Renesas Device Partition  (0xe5) means flash access error.

I am  afraid also that in this board you have enabled security settings that cannot be recovered.

Thanks and Regards,

IK

hey,

i can not see any garbage value on JMem. how are u able to see?

also, that is not the firmware file that i have attached. that is the JMem file i downloaded when i read the flash.

Thanks and regards,

Adithi K