Question: How to modify the flash kernels to run from the flash instead of the RAM?

Answer: On multibank devices, users can implement a custom bootloader in the flash to directly load application code onto the other flash banks. On single-bank devices, a custom bootloader in the flash can perform firmware upgrades on individual sectors within the same flash bank, but the Flash API must execute from RAM.

Using a custom bootloader provides more flexibility to the user in the boot flow, allowing for different peripheral GPIOs to be used as opposed to only having access to a limited, predefined set of GPIO assignments in the boot ROM. Having a custom bootloader also effectively reduces the number of steps in the bootloading process as there's no need to load an intermediate flash kernel into the RAM to program the flash.

Moreover, having a flash-based bootloader can also act as a fail-safe if the firmware upgrade process fails. Booting to code that does not get upgraded (that is, the flash-based bootloader) minimizes the chance that the device tries to boot to corrupted code, since the bootloader can use multiple methods to verify the existing firmware (key value, checksum, and so forth.). The same can be achieved in a RAM-based flash kernel too, but it's not practical to load this in every time the device boots.

One way to implement a custom bootloader is to modify the existing flash kernel projects in C2000Ware to execute from the flash instead of the RAM. This requires modifications to the kernel's linker command file, which specifies where the application is loaded in memory, and adding a pre-defined symbol to be used by the compiler.

1. Right-click the project and select Add Files/Folders.
   
   
   Figure 5-1 Adding a File to a Project into CCS
2. Navigate to the following path in C2000Ware and select the generic flash linker command file for the intended device.
   1. C2000Ware_X_XX_XX_XX\device_support\DEVICE_NAME\common\cmd
3. Right-click the RAM linker command file and select Exclude from Build, so the flash linker command file is used in the compiler build.
   
   
   Figure 5-2 Excluding the RAM Linker Command File from the Compiler Build
   Note:

   With the generic flash linker command file, the kernel is loaded into flash bank 0 (entry point at 0x80000). If users want to place the kernel in a different flash bank, then modify the SECTIONS allocated to flash bank 0 in the linker command file to the intended flash bank.

   Furthermore, in MEMORY portion of the linker command file, BEGIN must also be updated to the intended flash entry point location (codestart) as needed, including the flash bank origin and length specifications to account for the codestart allocation at the entry point.

   Refer to [33] for more details on linker command file directives.

4. Create a new build configuration by right-clicking the project and navigating to Build Configurations > Manage...
   
   
   Figure 5-3 Creating a New Build Configuration for the Project
   1. Name the build configuration CPU1_FLASH and opt to copy settings from the CPU1_RAM configuration.
      
      
      Figure 5-4 Creating the CPU1_FLASH Build Configuration
5. Set the active build configuration to CPU1_FLASH.
6. In device.c, the time critical code and flash setup code (called Ramfuncs) is copied to the RAM. Moreover, the flash initialization function to setup flash waitstates must reside in RAM. Since the kernel is executing in the flash now, the symbol _FLASH must be defined for these conditions to occur.
   1. Right-click and navigate to the Properties > Tools > C2000 Compiler > Predefined Symbols. Define the symbol _FLASH.
      
      
      Figure 5-5 Add the Predefined Symbol _FLASH to Initialize Flash Functions
7. Re-build the flash kernel project with the CPU1_FLASH build configuration. Now, the flash kernel is built to execute from the flash and can be programmed onto the device flash.
   Note: Since the kernel is already loaded onto the device, then the serial_flash_programmer_appIn.exe in C2000Ware must be used. This executable can be called with the same command line arguments as the normal serial flash programmer, but the kernel argument (-k) is not required.