Creating binary with Bootloader and application

[pejo]

Hi,

I'm developing a booloader for an LPC550X board. The bootloader should at a certain point in the code start the application. This application should be allocated in the flash memory at a fixed address. 

I'd like some help to create a binary, which we can flash to the board and which contains both binaries (bootloader and application).

Any ideas where to start?

Thank you!

[frank_m]

I would recommend using SREC/S19 or HEX files instead.

Since the BL and the application are in different sectors, both files would be easy to merge.
Occasionally I have even done so manually, i.e. copied the data contents of the BL into the SREC file of the application. Of course one need to consider structure and syntax of the S19 file format.

My company often used the "srec_cat" tool to join both in a post-build step.
This tool is part of the free "SRecord" package, which you will easily find with a search engine.

[pejo]

hi Frank,

thank you for your message. I'm unfortunately not very experienced with this platform. By default I'm creating ELF files after compilation from the console (or AXF from the MCUXpresso IDE). Is the SRC Format compatible with the ARM/Cortex M33 architecture? 

I've seen that with objcopy I can teoretically convert ELF to SRC Format but what I don't fully understand is how to tell to the resulting file that the BL should be in a given position in the FLASH and the Application in another position.

[frank_m · Accepted solution]

Yes, objcopy would work, too.
As a starter, here a link to a tutorial regarding this topic.
https://mcuoneclipse.com/2017/03/29/mcuxpresso-ide-s-record-intel-hex-and-binary-files/

> I've seen that with objcopy I can teoretically convert ELF to SRC Format but what I don't fully understand is how to tell to the resulting file that the BL should be in a given position in the FLASH and the Application in another position.

The S19 (SREC) and Intel HEX format contain both addresses and data.
These are basically human-readable text format files, that define both that target address and the data.
Since BL and application are in different sectors and thus different addresses, they don't interfere.
https://en.wikipedia.org/wiki/SREC_(file_format)

Although you might need to restrict yourself with the syntactically possible combinations of SREC/HEX files, because some flashing tools are poorly written in this regard.
While allowed by the SREC file format definition, I dealt with flashing tools that expected a fixed input line length, a fixed address size, and only ascending addresses.
The mentioned SRecord tool could deal with all this requirements.

[pejo]

Hi Frank,

I've tested it and flashed it to the board and it worked nicely. Thank you a lot !

Summary of operations:

* [srec_cat] Convert Application binary ->intel hex format with srec_cat

* [srec_cat] Convert intel hex Application to hex with offset 

* [objcopy] Create bootloader elf-> bootloader hex file

* [srec_cat] Merge hex files (Application hex file with offset + bootloader hex file)

* [srec_cat] Create final binary from merged intel hex file

[pejo]

hi Frank,

thank you a lot for the info. I'll try it next week and let you know what we find out and whether it worked. Have a nice WE.

[Pavel_Hernandez]

Hello, my name is Pavel and I will be supporting your case, maybe this tool is what are you looking for, with BLHOST you can send the command to write a certain region of the flash.

blhost -p COMxx write-memory 0x0 root.bin (for the bootloader)

blhost -p COMxx write-memory 0x6000 root.bin (for the image)

the command needs to modify the regions only for example.

To use the BLHOST I recommend install the SPSDK.

Installation Guide — SPSDK documentation

[pejo]

Thank you Pavel but what I'm trying to do is to create a binary containing both BL and Application which I can flash N times, not to flash BL and Application directly to the MCU (which is very useful indeed)