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, 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 sections. The user needs to define and allocate a .TI.update section in the linker command file. For the CLA LFU use-case, the recommendation is that the user handle it manually in their LFU code. CLA variable initialization on LFU is not supported by __TI_auto_init_warm() and needs to be managed in user code. The compiler will not handle warm initialization of CLA update variables.
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.
      Attention:

      Compiler version 25.11.0.LTS and later versions support a new mode called "all". This will be the default mode, and will always preserve (i.e. Same address and no LFU initialization) global/static variables that are common between the old and new firmware, and will always update (i.e. Goes into .TI.update and LFU initialization) global/static variables that are present only in the new firmware. This means it is not necessary for the user to explicitly add an attribute to global/static variables unless they want a different behavior e.g. They want a variable that's common between old and new firmware to get LFU initialization.

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 must not be used for CLA side global and static variables.

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