SPRADN0 December   2024 F29H850TU , F29H859TU-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Programming Fundamentals
  5. 2Introduction
    1. 2.1 Hardware Security Module
    2. 2.2 ROM Bootloader
    3. 2.3 Combined Image with X.509 Certificate
  6. 3Flash Kernel Implementation
    1. 3.1 CPU1 Firmware Upgrade (HS-FS)
    2. 3.2 Key Provision (HS-FS to HS-KP)
    3. 3.3 CPU1 Secure Firmware Upgrade (HS-KP/SE to HS-SE)
    4. 3.4 HSM Firmware Upgrade (HS-KP/SE to HS-SE)
    5. 3.5 SECCFG Code Provisioning (HS-KP/SE to HS-SE)
  7. 4Host Application: UART Flash Programmer
    1. 4.1 Overview
    2. 4.2 Build UART Flash Programmer with Visual Studio
    3. 4.3 Build UART Flash Programmer with CMake
    4. 4.4 Packet Format
    5. 4.5 Kernel Commands
  8. 5Example Usage
    1. 5.1 Loading the Flash Kernel onto the Device
      1. 5.1.1 Hardware Setup
      2. 5.1.2 Running the UART Flash Programmer
    2. 5.2 CPU1 Device Firmware Upgrade (HS-FS only)
    3. 5.3 Convert HS-FS to HS-SE
    4. 5.4 Loading a RAM-based HSMRt Image
    5. 5.5 Key Provision (HS-FS to HS-KP)
    6. 5.6 Code Provision (HS-KP/SE to HS-SE)
  9. 6Troubleshooting
    1. 6.1 General
    2. 6.2 UART Boot
    3. 6.3 Application Load
  10. 7Summary
  11. 8References

CPU1 Firmware Upgrade (HS-FS)

To perform a firmware upgrade for CPU1 of an HS-FS device, compile the CPU1_APP build configuration of the project. This can be done by right-clicking the project, hovering over Build Configurations, and selecting CPU1_APP.

In the case of a Device Firmware Upgrade (DFU) command, the following steps take place:

  1. The kernel in CPU1 receives the command packet to perform DFU.
  2. To prepare for a new application, the entirety of flash is erased before programming.
  3. The kernel prepares to receive the X.509 certificate from the host.
  4. The kernel verifies that the incoming certificate is of the proper size and format and derives the size of the incoming image. For now, the certificate is stored in RAM.
    1. While there is no authentication on the certificate or the incoming image during this process. The certificate needs to still be generated properly as the kernel infers the image size from the certificate and is authenticated during standalone flash boot routine.
  5. If the certificate size and format are accepted, then the kernel prepares to receive and program the new application to flash
  6. The kernel programs the incoming application in chunks of 1024 bits. After each chunk is programmed, the kernel verifies that the data and ECC were programmed correctly into flash.
  7. After successfully programming the entire image, the kernel then programs the associated certificate into the first 0x1000 addresses of FLC1 B0/B1. With the certificate programmed to this region of flash, the device is able to boot to the existing application in the standalone flash boot mode.

To generate an application image that can be loaded by the kernel, refer to the post-build step of Section 2.3. And see Section 5.1 for more details on usage.