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

3.5.8 Robustness

The sequence of Flash programming events related to LFU is:

  • In liveDFU(), the custom bootloader writes a START field to a specific Flash location in the Flash bank being programmed
  • Then the host transfers data to the device block by block (multiple bytes), which is stored in a buffer, checksum is returned to the host
  • Then the custom bootloader erases the corresponding Flash sector (if not already erased)
  • After the entire application image has been programmed, the custom bootloader writes a KEY field and updates the VERSION field in the Flash bank programmed. This indicates the presence of a valid application image in that Flash bank.

If the LFU process is interrupted due to a Power loss or Communication issue:

  • If the interruption did not result in a device reset (e.g. failure due to communication issue), then the custom bootloader will not be able to complete downloading the application image. However, the old ISRs from the application will continue to execute, but not the background tasks. Another LFU command cannot be initiated until a device reset is performed.
  • The Flash bank that was being written to would be partially programmed.
  • However, since the VERSION is not updated, on the next device reset, the custom bootloader will branch to the old application in Flash and full services are resumed, with the ability to again perform LFU.