need mcuboot flash signed image file format

Hi Everyone, I am in the process of creating an application using mcuboot. It's on an RA2 MCU, I have the bootloader loaded, the primary app loaded and running (using overwrite mode for now).

All of that works fine; however, this application will also have a service that uses a UART interface to upload a new image to be flashed. To do this I need to understand the file format of the signed binary image generated by the IDE - that is the header lengths, file lengths and so forth. I've inspected the file in hex mode and this is certainly not in .elf format. I haven't found a resource that describe this in detail. So any help someone could send my way would be appreciated.

  • Hello,

    Thank you for reaching out Renesas Engineering Community!

    Could you please provide as the exact name of the MCU you are using or a part Number?

    Thank you!

    Best Regards,

    IK

  • Regarding the format of the output file generated by e2studio IDE users have the ability to choose what kind of format the want to use:

    Go to Properties >> C/C++ Build >> GNU Arm Cross Create Flash Image >>General >>Output file format(-O) and you can choose one the available formats, as shown in the picture below:

    After building your project in Debug folder of the project you will find the image file generated with the format you have chosen.

    Hope it helps!

    Best Regards,

    IK

  • Hi,

    The MCUBoot update image is in binary format. It can be loaded at the update area address. So, say for simplicity the bootloader size is 0x10000 and the primary image is 0x18000. The update image should typically be located at 0x28000 (0x10000 + 0x18000). MCUBoot will look at the update image location when booting to see if a valid update is present. It will then overwrite (in your case) the primary image with the update image if it is accepted.

    The image format is described at;

    https://docs.mcuboot.com/design.html

    Regards,

    Ian.

  • Thanks Ian, but I already have the bootloader and initial image running. Using the IDE I loaded the primary image to the correct location and everything started up as expected. Now I need the main application to be able to fetch and store a new image to the secondary slot. And because the application is managing this, I need to know the image format to expect. 

    That said should I be loading the <application_name>.bin.signed image?

    More specifically I need to know all the details of what comprises the image file such as where in the image headers[s] I can determine the image size, number and sizes of headers and so forth

    The document you referenced describes in detail how the bootloader loads files already resident in flash, my need at hand is to transfer incoming bytes from a UART stream into the secondary flash slot. 

  • In my previous reply you would locate <application_name>.bin.signed at the start of the secondary slot which in the example is 0x28000.

    The below linked document shows where the header is located in the image (at the beginning).

    https://www.renesas.com/us/en/document/apn/secure-bootloader-ra2-mcu-series-application-project?r=1469021

    My previous post included a link showing the header structure. This can also be found in the FSP supplied source of MCUBoot. You should be able to determine the information you require from that.

    Ian.

  • Hello;

    I follow the instruction to did the RA2A1 secureBoot, I find the "Swap with signature" can't debug, all other three works fine for debugging.

    If binary file, all the data inside the file are programming data, no format at all. You need have the correct start address to write. 

    Hex file has format.

    Regards

    Sam 

  • Hi,

    That's correct. The binary file is the raw data to be programmed into the update area of the flash. It has no address information associated with the data. Intel hex and Motorola s-record files are text based files containing address and data information. These formats are not so useful when downloaded by an embedded system as the text formatted data needs to be parsed by the embedded device. They are useful when using a debugger or flash programmer to program the flash memory.

    Ian.