Combining a bootloader and user program into single flash-able binary

Question

I want to flash the UF2 bootloader for SAMD21 MCUs together with a compiled binary of a user program onto a SAMD21 MCU.

From what I understand how any bootloader works, the bootloader sits in a specific address space in the flash (in case of UF2 it seems to be 0x0-0x00002000) and then after that address space the bootloader will flash the user program and execute it.

Now it would be great if I can program my board with the bootloader and the default user programm all in once without needing to flash the bootloader with the programmer first and then connecting the board via USB to flash the user program.

Can I somehow concat the binaries so the programmer can flash everything at once in a single operation?

I planned on using https://github.com/adafruit/Adafruit_DAP with a Teesny for flashing. This works great using only the bootloader binary.

Answer 1

You've inaccurately specified the bootloader address, and that's important.

If the regions the bootloader and application programs would occupy are contiguous with at most a little padding to allow growth of future bootloader versions, then you can simply concatenate the binaries (with padding) and produce a single flat binary. If both are going into the same user flash bank, that would typically be the case. But if the regions are distcontinuous, then you'd need a format like an Intel Hex or s-record file or a .elf which can accommodate jumps to various addresses.

With a GCC style toolchain (as Atmel themselves now offer for their ARM parts) you can typically use the arm-none-eabi-objcopy (middle identification may vary) to manipulate and combine .elf, hex, and flat binary files. For simple cases you can also combine flat binaries with cat (if no padding is needed) or dd (if it is), and combine .hex files with cat or a scriptable text editor, possibly after stripping off any whole-file metadata.

For a typical program including the bootloader you are looking at, you'll find the actual memory assignments in the linker script (.ld) file, and you can find the usage of objcopy to produce a flat binary in the project Makefile.

Note that generally you want to build and link each of the bootloader and the application program as independent projects; you don't want the linker trying to share anything between them, except possibly for things you define at fixed dispatch addresses; otherwise it becomes near impossible to change one without requiring a rebuild of the other, which largely defeats the purpose of having a bootloader. When I do bootloaders for ARM-based systems, I typically just have the bootloader parse the vector table at the start of the application program, mimicking what the hardware itself does on startup; that also makes it possible to simply copy the application program's vector table to the hardware start address and have the chip start directly into the application without a bootloader, which can simplify debugging.

Answer 2

1)

Depending on your toolchain, you may be able to take the binary of your application firmware that you get after compiling, and use the bootloaders linker file to link in the applications binary file to the correct address range.

2)

You can use an SRecord tool like http://srecord.sourceforge.net/. There are command line tools to manipulate srec files and convert to binary and back.

I suggest creating a batch file so you don't have to do this manually every time you compile and test.

3)

This is the most time consuming to implement. But if you do a lot of bootloaders and have different MCUs and platforms, this could automate a lot and save you time.

You can create your own PC application that takes binary files or srec files and a configuration file. Then it will combine the bootloader with the application and generate any other files you may want, like an encrypted file, inject an AES key into the image, push to testing, create log files, etc. But this may not be the way to go the first time around.

Notes:

Note that i'm assuming you have already edited the application to support a bootloader, such as editing the linker file to start at the correct address you need it to go once it's combined with the bootloader. Also that you already have the application re-locating the interrupt vector table to another location, and that the bootloader knows where to jump into the application and to verify the checksum of the application before booting it.

Once all that is done, then you can generate the binary file and combine it with the bootloader.

Answer 3

Take a look at SRecord - it was designed with this goal in mind. It handles not only binary files, but also many other formats, such as Intel HEX and Motorollla HEX.