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

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

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