SPRUIU8B August   2020  – March 2026 TMS320F280040-Q1 , TMS320F280040C-Q1 , TMS320F280041 , TMS320F280041-Q1 , TMS320F280041C , TMS320F280041C-Q1 , TMS320F280045 , TMS320F280048-Q1 , TMS320F280048C-Q1 , TMS320F280049 , TMS320F280049-Q1 , TMS320F280049C , TMS320F280049C-Q1

 

  1.   1
  2.   Live Firmware Update With Device Reset on C2000 MCUs
  3.   Trademarks
  4. 1Introduction
  5. 2Resources Required for LFU
  6. 3Memory Layout
  7. 4Static Code in LFU
  8. 5LED Example Application and LFU Flow
  9. 6Running the LED Example
    1. 6.1 Serial Flash Programmer Update
    2. 6.2 Programming Static Code – Loading via Code Composer Studio (CCS)
    3. 6.3 Live Firmware Update of Application
    4. 6.4 Limitations and Troubleshooting
  10. 7Extended Implementations
    1. 7.1 Live Firmware Update with Reset on F28P65x MCUs
      1. 7.1.1 F28P65x LFU Hardware Requirements
      2. 7.1.2 Flash Organization
      3. 7.1.3 FWU Boot Mode
      4. 7.1.4 LED Example Application
        1. 7.1.4.1 LFU Command Processing
      5. 7.1.5 Running the Example
        1. 7.1.5.1 Loading the Example
        2. 7.1.5.2 Combing CPU1 and CPU2 Firmware Images
        3. 7.1.5.3 LFU over MCAN Host Programmer
          1. 7.1.5.3.1 Compiling the Host Programmer
          2. 7.1.5.3.2 Using the Host Programmer
      6. 7.1.6 Restrictions
  11. 8Revision History

7.1.5.1 Loading the Example

Both the host and client expect to read/receive images in the TI ASCII hex format, which can be generated by adding the following post-build step to your project:

"${CG_TOOL_HEX}" "${BuildArtifactFileName}" -boot -sci8 -a -o "${BuildArtifactFileBaseName}.txt"

To perform the flash A/B swap, two linker file versions are employed to toggle between using CCS build configurations, each placing the application in a different flash bank. For this example, the following scheme is used:

Table 7-2 Flash Bank Organization
Application Flash Bank Entry Point FWU Boot Option
CPU1 FW Version A 2 0x000C 0000 0x0B
CPU1 FW Version B 3 0x000E 0000 0x0B
CPU2 FW Version A 0 0x0009 0000 0x4B
CPU2 FW Version B 1 0x000B 0000 0x4B
Note:

CPU1 and CPU2 must use different FWU boot options to avoid conflicts between booting the CPU1 and CPU2 firmware after a device reset.

After generating the application images, the initial versions need to be loaded onto the device through the following procedure:

  1. Configure CPU1 for FWU boot mode 0 (BOOTDEF = 0x0B). Users can do this in emulation boot by configuring the emulation boot registers at addresses 0xD00-0xD01 and 0xD04 in the memory browser.
    1. Users can also program the boot registers in the DCSM OTP to configure device for standalone FWU boot. Please refer to Getting Started with C2000 Bootloading on C2000 Microcontrollers for more details.

      Emulating FWU Boot using CCS Memory Browser
      Figure 7-3 Emulating FWU Boot using CCS Memory Browser
  2. Configure CCS Flash Settings for CPU1 to load the image by allocating the flash banks to the correct CPU. In this case, CPU2 is allocated Banks 0 and 1.

    Flash Bank Mapping in CCS CPU1 Flash Settings
    Figure 7-4 Flash Bank Mapping in CCS CPU1 Flash Settings
  3. Configure the CCS Flash Settings for CPU1 to not erase CPU2’s Flash Banks by using the "Selected Banks Only" setting.

    CPU1 Flash Bank Erase Settings
    Figure 7-5 CPU1 Flash Bank Erase Settings
  4. Load the CPU1 application image.
  5. Run CPU1.
    1. CPU1 allocates GS4RAM and Flash Banks 0 + 1 to CPU2. Therefore, CPU2 variables can be properly initialized on CPU2 application load.
  6. Configure the CCS Flash Settings for CPU2 to not erase CPU1’s Flash Banks.

    CPU2 Flash Bank Erase Settings
    Figure 7-6 CPU2 Flash Bank Erase Settings
  7. Load the CPU2 application image.
  8. Run CPU2.