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

3 Flash Kernel Implementation

When compared to the C28-based designs, the UART flash kernel for F29H85x is quite different due to the integration of the HSM. A high-level overview of the features implemented in this example is provided below.

  • CPU1 DFU (HS-FS only)
    1. Device need to be configured for Bank Mode 0.
    2. Flash kernel in CPU1 programs application to the flash banks.
    3. Certificate is programmed in 0x10000000 - 0x10000FFF, certificate is not used for authentication but rather to infer the size of the kernel binary.
    4. Application can be programmed in the remaining flash addresses, and TI recommends to program codestart at 0x10001000. As 0x10001000 is the flash entry address in flash boot mode.
CAUTION: For users not concerned with the security features provided by the HSM, simply use the CPU1 DFU flow to upgrade the CPU1 firmware.
  • Load HSMRt (prerequisite for Key & Code Provisioning)
    1. Flash kernel in CPU1 receives key provisioning HSM run-time (HSMRt) and places in LDAx RAM.
    2. HSM authenticates HSMRt image and begin executing the run time in LDAx RAM.
  • CPU1 Key Provisioning (HS-FS -> HS-KP )
    1. Flash kernel in CPU1 loads HSMRt
    2. Flash kernel receives key certificate and places in LDAx RAM
    3. HSM validates key certificate and programs them to OTP
  • CPU1 Code Provisioning (HS-SE only)
    1. Flash kernel in CPU1 loads in HSMRt
    2. Flash Kernel receives the CPU1 application image certificate and shares the same with HSMRt
    3. After successful authentication of the image, HSMRt responds with an acknowledgment, after which flash kernel starts importing the chunk of data via UART into the LDAx memory.
    4. After each 16KB (size of LDAx memory) of data received, the flash kernel sends an HSM requests to program the data for further processing
    5. After all chunks are received and programmed, HSMRt is requested to verify the code programmed in HSM active and dormant banks. When the HSMRt firmware authenticates the programmed image against the certificate, the certificate is further programmed to make sure of a successful boot in the subsequent power cycles.
    6. Upon successful authentication, the HSM programs the firmware to CPU1 flash
  • HSM Code Provisioning ( HS-KP/HS-SE -> HS-SE )
    1. Flash kernel in CPU1 loads in HSMRt
    2. Flash kernel receives the HSM application image certificate and shares the same with HSMRt
    3. After successful authentication of the image, HSMRt responds with an acknowledgment, after which flash kernel starts importing the chunk of data via UART into the LDAx memory.
    4. After each 16KB (size of LDAx memory) of data received, the flash kernel sends an HSM requests to program the data for further processing
    5. After all chunks are received and programmed, HSMRt is requested to verify the code programmed in HSM active and dormant banks. When the HSMRt firmware authenticates the programmed image against the certificate, the certificate is further programmed to make sure of a successful boot in the subsequent power cycles.
  • SECCFG Code Provisioning (HS-KP -> HS-SE )
    1. Flash kernel in CPU1 loads in HSMRt
    2. Flash kernel receives the image certificate and shares the same with HSMR
    3. After successful authentication of the image, HSMRt responds with an acknowledgment, after which flash kernel starts importing the SecCfg data via UART into the LDAx memory
    4. After all the SecCfg data are received and programmed, the HSMRt is requested to verify the SecCfg programmed in the dormant banks with valid counter values. When the HSMRt authenticates the programmed image against the certificate, the certificate is further programmed to make sure of a successful boot in the subsequent power cycles.
    5. Note in the case of HS-SE device, the decision of programming of the certificate is made on the swap value of the SSU registers.
CAUTION:

Key and code provision both require a RAM-based HSMRt image to be running on the HSM. Nonetheless, the image requires a different key certificate at each stage of provisioning.

In key provisioning, user must provide the HSMRt image with default TI key certificate to complete authentication on an HS-FS device, whereas code provisioning requires an image with user key certificate to complete authentication on an HS-KP/HS-SE device.

The OTP Keywriter firmware described in the Hardware Security Module section contains a binary image that can perform these tasks.

The UART flash kernel is designed for CPU1 while in Bank Mode 0. This means that all flash banks are allocated to CPU1 and the bank swapping feature is not available. For more details on Bank Modes, please see the Bank Modes and Swapping section of the TRM. The flash kernel communicates with the host PC application provided in the F29H85x MCU SDK (MCU_SDK_F28H85x > utilities > flash_programmers > serial_flash_programmer) and provides feedback to the host on the receiving of packets and completion of commands given.

After loading the kernel into RAM and executing by the UART ROM bootloader, the kernel first initializes the PLLs, GPIOs, the UARTA module, and the flash module. The UART communication is configured with a baud rate of 115200, similar to the UART boot flow. After this, the kernel begins a while loop, which waits on commands from the host, executes the commands, and sends a status packet back to the host. This while loop breaks when a Run or Reset command is sent.

Commands are sent in a packet described in Table 4-2 and each packet is either acknowledged or not-acknowledged. All commands, except for Run and Reset, send a packet after completion with the status of the operation. The status packet sends a 16-bit status code and 32-bit address. In case of an error, the address in the data specifies the address of the first error. In case of NO_COMMAND_ERROR, the address is 0x1000.