TIDUEY4D August   2022  – December 2022

 

  1.   Description
  2.   Resources
  3.   Features
  4.   Applications
  5.   5
  6. 1System Description
    1. 1.1 Key System Specifications
  7. 2System Overview
    1. 2.1 Block Diagram
    2. 2.2 Design Considerations
      1. 2.2.1 Building Blocks
      2. 2.2.2 Flash Partitioning
      3. 2.2.3 LFU Switchover Concepts
      4. 2.2.4 Application LFU Flow
  8. 3Hardware, Software, Testing Requirements, and Test Results
    1. 3.1 Hardware Requirements
    2. 3.2 Software Requirements
      1. 3.2.1 Software Package Contents
      2. 3.2.2 Software Structure
    3. 3.3 Introduction to the TIDM-DC-DC-BUCK
    4. 3.4 Test Setup
      1. 3.4.1 Loading the Custom Bootloader and Application to Flash using CCS
    5. 3.5 Test Results
      1. 3.5.1 Running the LFU Demo with Control Loop Running on the CPU
      2. 3.5.2 Running the LFU Demo with Control Loop Running on the CLA
      3. 3.5.3 LFU Flow on the CPU
      4. 3.5.4 LFU Flow on the CLA
      5. 3.5.5 Assumptions
      6. 3.5.6 Preparing Firmware for LFU
      7. 3.5.7 LFU Compiler Support
      8. 3.5.8 Robustness
      9. 3.5.9 LFU Use-Cases
  9. 4FOTA Example
    1. 4.1 Abstract
    2. 4.2 Introduction
    3. 4.3 Hardware Requirements
    4. 4.4 Software Requirements
    5. 4.5 Running the example
  10. 5Design and Documentation Support
    1. 5.1 Software Files
    2. 5.2 Documentation Support
    3. 5.3 Support Resources
    4. 5.4 Trademarks
  11. 6Terminology
  12. 7About the Author
  13. 8Revision History

4.2 Introduction

Where remapping of Flash banks is not available, each Flash bank is mapped to a fixed memory address. During LFU, the firmware executable is programmed to the Flash bank that is currently inactive, while the application continues to run from the Flash bank that is currently active. With this approach, the user needs to be aware of which Flash bank their firmware executable is targeted for. Thus, they need to maintain 2 linker command files for their project (if they are using 2 Flash banks). This can be cumbersome, so an alternate solution is proposed and implemented here.

In this approach, the firmware executable is always built to be Loaded to Flash Bank1 and Run from Flash Bank0. This can be done with just one linker command file. Similar to how functions in an application are Loaded to Flash and Run from RAM for performance improvement, a memory copy is needed here as well. This is implemented in the LFU bootloader i.e. Flash kernel. The Flash Bank1 to Bank0 memory copy takes about 1 second to complete.

As mentioned before, this example can be used as a reference for FOTA, with a few functional features not implemented:

  • Rollback – to support a rollback, a copy needs to be done from Flash Bank0 to Bank2, prior to the Bank1 to Bank0 copy. This can done exactly along the lines of the Bank1 to Bank0 copy illustrated in the Flash kernel.

  • Reset – this example does not implement a full device reset after the Bank1 to Bank0 copy. That is how FOTA would work. In this example, once the memory copy is complete, the Flash kernel directly branches to the entry point of the application, where c_int00 is called and then main().