1.11 Bootloader Development Considerations

What is the maximum size of the bootloader that is allowed given the target application space and the size of the flash? The bootloader owner should also provide an extra buffer to allow for some increase in the bootloader size over the lifetime of the project. If the size of the bootloader needs to increase, it will impact all of the existing application projects.

What is the method to verify the application? The example code that MCC generates checks to see if the first address of code is valid. While this is valid, it has a relatively low coverage. The user may want to implement a CRC checking routine. HEXMATE does provide different tools to help with calculating the checksum of data within a hex file.

The bootloader owner also needs to make all developers on the application side agree on the list of interrupts being forwarded to specific handlers and the default handler.

The bootloader owner needs to make sure all developers on the application side agree on the configuration bit settings. It's important to re-verify that the config bits match between the bootloader and application by using MCC on the application project before using the bootloader to download the code. MCC will go a re-verify that the config bits between the bootloader::bootloader and bootloader::application still match.

The bootloader owner needs to create the final code for any options like boot up options or indicator options. In addition, if any of the peripherals on the device are modified from their reset settings, the application owners need to be notified as they may need to address these differences when configuring their devices.

If the bootloader enabled any interrupts or peripherals then they should be disabled before branching to the application code. For instance, if the bootloader code enabled the Timer and Timer Interrupt. If these are not enabled prior running the application code, they can cause unexpected Timer Interrupts in the application code leading to system crashes and unexpected events. One common failure mode is a device reset. Since there may be no interrupt handler for this interrupt in the application, a device reset could occur. Upon device reset, the bootloader will then run again, it will enable these interrupts and verify the application code. The application code will run again with the Timer interrupt enabled and cause the sequence to repeat continually. Likewise, if the UART was configured in the bootloader and not disabled prior to running the application, random noise on the wires or unexpected baud rate changes could cause the UART to see phantom data or frame errors leaving the UART in an unexpected state when the application takes control of the UART.

If the user decides to enable the IOL1WAY bit, this means bootloader will configure all of the PPS registers and lock them prior to running the application. The application will not be able to change the values preventing the application from accessing the needed functions on these pins. In this case, the combined bootloader and application PPS configuration needs to be merged and programmed at boot time. This requires the user to manually update the values programmed into these register in the bootloader code and remove this step from the application code.