SPRADS1 June   2025 F29H850TU

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
    1. 1.1 Hardware Security Module
    2. 1.2 Flash Programming Fundamentals
    3. 1.3 High-Level Flow
    4. 1.4 Flow Chart
  5. 2Flash-Based UART SBL with FOTA
    1. 2.1 Implementation
    2. 2.2 Triggering a Bank Swap
  6. 3FOTA_Example_Application
    1. 3.1 led_blinky_cpu1.c
    2. 3.2 Combining the Flash-Based SBL with the FOTA_Example_Application
    3. 3.3 Adding a CPU3 Application
  7. 4Host Application: UART Flash Programmer
    1. 4.1 Overview
  8. 5Example Usage
    1. 5.1 Loading the SBL onto the Device
      1. 5.1.1 Loading by CCS (JTAG)
      2. 5.1.2 Loading via UART Boot and the UART Flash Kernel
    2. 5.2 Example UART Loading Process
  9. 6FAQ
    1. 6.1 General
    2. 6.2 Application Load
  10. 7Summary
  11. 8References

1.3 High-Level Flow

On an HS-FS device, the flash-based UART SBL with FOTA project follows this flow:

  1. Boot to flash (standalone or emulation boot).
  2. Initialize device (clocks, GPIOs, peripherals, and so forth).
  3. Compare the current bank mode to the bank mode in which the most recent successful firmware upgrade occurred.
    1. If this is the first time the device has booted and the SBL or application was loaded through CCS or JTAG, then the SBL bypasses this check.
    2. This is possible to boot existing firmware after a bank mode change, but, this example requires a firmware upgrade every time the bank mode changes.
  4. If the current bank mode is the same as the previous bank mode, then start the timeout period to wait for a firmware upgrade command (5 seconds). If the bank mode has changed, then the device waits indefinitely for a firmware upgrade and does not attempt to boot to existing firmware.
  5. If a firmware upgrade command is received, then CPU1 receives the firmware and programs the upgrade over UART for the requested CPU (CPU1 or CPU3).
  6. If no firmware upgrade command is received before the timeout, then branch to the application entry point and begin executing.
  7. Once the application is executing, interrupts are configured to make sure that a firmware upgrade command can be received and processed over UART.
  8. If the firmware upgrade command is received, then the application branches to the SBL code and performs the requested firmware upgrade. Any application ISRs in the existing application is serviced throughout the duration of the firmware upgrade.
  9. Once the firmware has been successfully programmed to the inactive flash region, the SBL programs the inactive BANKMGMT region such that a swap is triggered on a device reset.
    1. For more details on bank swaps, refer to Section 2.2.
  10. If successful, then CPU1 programs the current bank mode to the first byte of the data flash. This indicates the bank mode of the most recent successfully firmware upgrade next time the device boots.
  11. After the firmware upgrade is completed, the SBL returns control to the application if this exists.
  12. If successful, then a bank swap is triggered and the new firmware executes after a device reset.

On an HS-SE device, the flash-based UART SBL with FOTA project follows this flow:

  1. Boot to flash (standalone or emulation boot)
  2. Initialize device (clocks, GPIOs, peripherals, and so forth.)
  3. Compare the current bank mode to the bank mode in which the most recent successful firmware upgrade occurred.
    1. If this is the first time the device has booted and the SBL or application was loaded through CCS or JTAG, then the SBL bypasses this check
    2. This is possible to boot existing firmware after a bank mode change, but for the sake of simplicity this example requires a firmware upgrade every time the bank mode changes.
  4. If the current bank mode is the same as the previous bank mode, then start the timeout period to wait for a firmware upgrade command. If the bank mode has changed, then the device waits indefinitely for a firmware upgrade and does not attempt to boot to existing firmware.
  5. If a firmware upgrade command is received, then CPU1 receives the firmware and sends to the HSM in chunks. The HSM authenticates and programs each chunk to the inactive flash.
  6. Once all chunks have been programmed by the HSM, CPU1 requests the HSM to perform an integrity check on the firmware and programs the certificate to flash.
  7. If no firmware upgrade command is received before the timeout, then branch to the application entry point and begin executing.
  8. Once the application is executing, interrupts are configured to make sure that a firmware upgrade command can be received and processed over UART.
  9. If firmware upgrade command is received, then the application branches to the SBL code and performs the requested firmware upgrade. Any application ISRs in the existing application is serviced throughout the duration of the firmware upgrade.
  10. Once the firmware has been successfully programmed to the inactive flash region, the SBL programs the inactive BANKMGMT region such that a swap is triggered on a device reset.
  11. If successful, then CPU1 programs the current bank mode to the first byte of the data flash. This indicates the bank mode of the most recent successfully firmware upgrade next time the device boots.
  12. After the firmware upgrade is completed, the new firmware executes after a device reset.
Note:

The general process of a FOTA upgrade is similar between HS-FS and HS-SE devices, but the key difference is the integration of the HSM. The HSM is responsible for authenticating existing and incoming flash image, programming the authenticated incoming image, and performing an integrity check of the incoming image. On an HS-FS device, these steps are not required. CPU1 is responsible for receiving the incoming image and programming to flash without any authentication or integrity checks.