This section describes the steps involved in utilizing compiler support for LFU.

1. The Compiler version required for LFU support is 21.6.0.LTS or later.
2. Assuming the BANK0_FLASH build configuration is the old firmware, the path to its output executable needs to be provided as a reference image to the BANK1_FLASH build configuration. This will allow the compiler to identify common variables and their locations, and also identify new variables. This is done as follows (for F28004x) in the BANK1_FLASH build configuration projectspec:
   --lfu_reference_elf=${CWD}\..\BANK0_FLASH\buck_F28004x_lfu.out

   Likewise, for F28003x, --lfu_reference_elf=${CWD}\..\BANK0_FLASH\buck_F28003x_lfu.out

3. The compiler defines 2 new attributes for variables, called preserve and update. Preserve is used to maintain the addresses of common variables between firmware versions. Update is used to indicate new variables that the compiler can assign addresses without constraints and also initialize during the LFU initialization routine __TI_auto_init_warm(). Examples for how these attributes can be used are listed below:
   float32_t __attribute__((preserve)) BUCK_update_test_variable1_cpu;
   float32_t __attribute__((update)) BUCK_update_test_variable2_cpu;
4. If the user builds the BANK1_FLASH configuration as above, with the BANK0_FLASH image as the reference image, then the generated .map file will contain .TI.bound sections corresponding to the preserve variables. Additionally, if the user specifies variables with the update attribute (C28x side or CLA side), the .map file will contain a single .TI.update section where all the update variables are collected into. They will not be placed in the .bss or .data or .bss_cla sections. The user needs to define and allocate a .TI.update section in the linker command file.
5. To make things easier for the application developer, different LFU modes are available. The default mode is called preserve (not to be confused with the corresponding variable attribute described above), which can be explicitly specified as follows in the BANK1_FLASH build configuration projectspec:
   --lfu_default=preserve

   This mode has the following properties:

   1. If a reference (old) image is provided, then common variables don’t need to be specified as preserve. This will be the default attribute for common variables, and the RTS library will not initialize them in the LFU initialization routine. This helps maintain state.
   2. Any new variables that do not have any attributes specified will be assigned addresses, but they also will not be initialized in the warm-start LFU routine. If the user wants the LFU initialization routine to initialize the new variables, they need to be declared with the update attribute.
6. The complete list of LFU modes supported by the compiler in this release are called “none” and “preserve”. They have the following properties:
   1. none: Do not preserve any global and static variable addresses by default or initialize any variables during warm start by default.
      1. If preserve attribute is explicitly specified, then preserve the address of the variable.
      2. If update attribute is explicitly specified, then initialize the value of the variable during warm start. Address can move in memory.
   2. preserve: Preserve all global and static variables addresses found in the reference ELF unless the update attribute is specified for a variable.
      1. No need to specify preserve attribute for common variables. If preserve attribute is explicitly specified for a variable in reference ELF, it has the same behavior as not having been specified.
      2. If update attribute is explicitly specified, then initialize the value of the variable during warm start. Otherwise, do not initialize during warm start. In both cases, address can move in memory.
7. The RTS library provides an LFU initialization routine (__TI_auto_init_warm()). It initializes any new variables per the rules described above.
   1. The routine performs initialization of C28x CPU side global and static variables. This includes zero initialization (default) and non-zero initialization (if a non-zero value is specified).
   2. The routine performs only zero initialization of CLA side global and static variables. Non-zero initialization of CLA side global and static variables is not supported. Even though the compiler does not support initialization (zero or non-zero) of CLA side global and static variables in the startup C initialization routine, it does support zero initialization in __TI_auto_init_warm().
   3. As stated earlier, the routine is not impacted by the NOINIT pragma applied to section(s) in the linker command file.

For additional information, refer to the LFU section of the TMS320C28x Optimizing C/C++ Compiler User's Guide.