1.4.2 Application Builder

After the bootloader project has been defined and created in MCC, the next step is to create the application which the bootloader will co-exist with. The reason why the word "co-exist" was used is because every time the device is reset, the device first runs the bootloader which may pass control over to the application. In addition, all interrupt execution starts with an interrupt vector in the IVT located within the bootloader memory space. Finally, not only do both programs co-exist, they each use the same system configuration bits when running together so it's critical that both programs are expecting to use the same settings. If they don't for example, and the application program is expecting one PLL setting and the bootloader configuration bits could actually program the PLL bits differently. So instead of the system running at one frequency, it and all the peripherals could be running at a different frequency. This was just a single example of a single configuration setting.  

Figure 1-8.  Application Configuration Screen
 

The four main purposes of the application builder are to

  1. Configure the memory space settings to match the ones defined in the original bootloader project. This includes the start address of the application and the start address of the Application Remapped Interrupt Table.

  2. To verify that the configuration settings of the application match the bootloader settings.

  3. To copy the interrupt settings over from the bootloader so the application will using matching interrupts interrupt settings and vectors. In addition, it will define and place the interrupt vectors at the correct location in the Remapped Interrupt Vector Table.

  4. If one of verification methods is chosen, allow the user to update the address range used for verification. Details for the verification method can be found here. Application Verification.

16-bit Bootloader:Application Builder screen is shown below. Its only purpose is to read the memory map, interrupt configuration and chip configuration data directly from the bootloader project. The user needs to browse to the location of the bootloader project being used and select the project folder. Once selected, the application builder will read the project and the configuration information from the bootloader project. Once the bootloader project information is loaded, the application builder will use the information to set the memory addresses and verification method. It will check to make sure the application project has the same configuration settings and interrupt sources. If it finds a conflict it will display what the conflicts are that needs to be fixed.

The window shown below is for a bootloader which used the checksum verification method Application Verification. The default address range for the checksum verification method for this device is displayed here. The user is allowed to change the address range to any address for the checksum as long as the address resides within this device's default range. If the address chosen lies outside of the default range, an error will be displayed on the configuration screen. The default range covers the entire application range except for the few bytes where the checksum is actually stored.

Over the life of the project, the user may have changed some of the configuration bits by updating different modules. These setting will now conflict with the ones in the bootloader. This will be an issue when the user switches to booting the device using the bootloader instead of the configuration bits in this standalone project. So it's highly recommended that this screen be opened during the development of the project and at the end the of the project. When the user re-visits this MCC screen , it will re-verify the configuration settings in this standalone project with the configuration settings in the bootloader. If a difference is found, the user has two options. Either revert the changes in the application to match the bootloader or go back to the bootloader and change the settings there to match the application. While some configuration bits can be overridden at run time, it can be an extremely difficult procedure if it's even possible since most config settings cannot be over-ridden at run time.