Bootloader Considerations

A bootloader is a small application located in the Boot section, and its main purpose is to update the application section when needed. Typically the bootloader communicates with a host via a serial communication interface and the host provides the bootloader with the new application code.

A simple bootloader must be forced to do an update, i.e. by a button being pushed, whereas a more advanced bootloader can initiate an update when needed. Typically, on start-up, the bootloader will check if the application code is still valid, and if it is not, it will initiate an update. If no update is needed, the execution is transferred from the bootloader to the application code.

When using CRCSCAN in combination with a bootloader and application code, it is highly recommended that the bootloader handles the use of CRCSCAN. It is reasonable to assume that the application code is more frequently updated, hence the bootloader will be assumed to be the most trustworthy part.

When a bootloader is used to upload new firmware, only the application section of the Flash will be updated, and as CRCSCAN always includes the Boot section, one must make sure that the new checksum added at the end of the application section takes the old Boot section into consideration.

One of the easiest solutions is to calculate a separate checksum for the Boot section, and adding this at the end of the Boot section which will result in a checksum of 0x0000 when CRCSCAN has calculated the Boot section. This method results in the initial seed for the application code is the same, independent of changes in the bootloader code. In other words, when updating the application code, the new pre-calculated CRC checksum can be based on the application code only. An example for matching post-build commands are given below, with the necessary configurations for CRCSCAN, fuses, and project.

CRCSCAN Configuration

In this example, any CRCSCAN mode can be used, but CRCSCAN should be configured to scan the Boot and Application sections.

Fuse Configuration

In this example, the Boot section is 512B and the Application section is 3.5 KB. The fuses will have to be set accordingly.

BOOTEND = 0x02
APPEND = 0x10

Atmel Studio Project Setting for Application Code

In this example, the Application section will start at 0x200, which is achieved by a memory relocation in Atmel Studio.

Project→<project_name> Properties→Toolchain→AVR^®/GNU Linker→Memory Settings→FLASH segment→.text=0x100
Info: .text is the location of the code in a project, and Memory Settings is 16-bit addressed.

Post-build Command for Bootloader Code

srec_cat "$(OutputDirectory)\$(OutputFileName).hex" -intel -crop 0 0x1FE -fill 0xFF 0 0x1FE -CRC16_Big_Endian 0x1FE -broken -o "$(OutputFileName)_crc.hex" -intel -line-length=44

Info: The post-build command will take the generated <project_name>.hex file from the build output, fill the remaining space of the 512B Boot section with 0xFF, calculate the CRC, and put the CRC checksum at the last two bytes of the 512 KB block, address 0x1FE. The resulting file will be named <project_name>_crc.hex.

Post-build Command for Application Code

srec_cat "$(OutputDirectory)\$(OutputFileName).hex" -intel -crop 0x200 0xFFE -fill 0xFF 0x200 0xFFE -CRC16_Big_Endian 0xFFE -xmodem -o "$(OutputFileName)_crc.hex" -intel -line-length=44

Info: The Application section is located at address 0x200-0x1000, in this example, and xmodem provides the CRC checksum calculation with an initial seed of 0x0000. The post-build command will take the generated <project_name>.hex file from the build output, fill the remaining space of the 3.5 KB Application section with 0xFF, calculate the CRC, and put the CRC checksum at the last two bytes of the 3.5 KB block, address 0xFFE. The resulting file will be named <project_name>_crc.hex.