SPMA083 January   2022 TM4C129CNCPDT , TM4C129CNCPDT , TM4C129CNCZAD , TM4C129CNCZAD , TM4C129DNCPDT , TM4C129DNCPDT , TM4C129DNCZAD , TM4C129DNCZAD , TM4C129EKCPDT , TM4C129EKCPDT , TM4C129ENCPDT , TM4C129ENCPDT , TM4C129ENCZAD , TM4C129ENCZAD , TM4C129LNCZAD , TM4C129LNCZAD , TM4C129XKCZAD , TM4C129XKCZAD , TM4C129XNCZAD , TM4C129XNCZAD

 

  1.   Trademarks
  2. 1Implementation
    1. 1.1 Flash Boot Loader Project
      1. 1.1.1 Changes to the Example Project boot_serial
        1. 1.1.1.1 Changes to bl_config.h
        2. 1.1.1.2 New Functions Added
          1. 1.1.1.2.1 MyCheckUpdateFunc
          2. 1.1.1.2.2 MyReinitFunc
          3. 1.1.1.2.3 MyEndFunc
          4. 1.1.1.2.4 MyDecryptionFunc
    2. 1.2 Image Creation Project
    3. 1.3 Key Image Project
    4. 1.4 EK-TM4C129EXL Example Application Project
    5. 1.5 DK-TM4C129X Example Application Project
    6. 1.6 RAM-Based EEPROM Erase Project
  3. 2Example Walk Through
    1. 2.1 Build Environment
    2. 2.2 Importing the Examples into Code Composer Studio
    3. 2.3 Setting Keys and Variables
      1. 2.3.1 Keys
      2. 2.3.2 Initialization Vector
      3. 2.3.3 Application Start Address and Flash Size
        1. 2.3.3.1 APP_BASE
        2. 2.3.3.2 APP_END
        3. 2.3.3.3 RAM_BASE
    4. 2.4 Running the shared_key_image_encrypt Tool
    5. 2.5 Running the Shared Key Serial Boot Loader
      1. 2.5.1 Programming the Boot Loader
        1. 2.5.1.1 Erasing Existing Code and Keys
          1. 2.5.1.1.1 Erasing Flash and EEPROM With Code Composer Studio
          2. 2.5.1.1.2 Erasing Flash and EEPROM by Using the Unlock Procedure
        2. 2.5.1.2 Using the ROM Boot Loader to Program the Shared Key Boot Loader
      2. 2.5.2 Using the Shared Key Boot Loader to Program the Application Code
    6. 2.6 Returning to the Boot Loader
  4. 3Summary

1.1 Flash Boot Loader Project

The flash boot loader project shared_key_boot_serial is an example based on the current flash serial boot loader implementation with these additional features:

  • The boot loader exists in the first 16KB of flash space
  • The boot loader checks for 256-bit keys stored in two blocks of EEPROM.
  • If no valid keys are found (keys that are all FFs are invalid):
    • The boot loader enters a mode waiting to upload an image without decrypting that image. If the image starting at 0x4000 contains only 1 to 4 valid keys, those keys are copied to the EEPROM and the sector at 0x4000 is erased.
    • The boot loader checks that JTAG is disabled. If not, it disables JTAG, and write protects the first sector of flash (release configuration only).
  • If a valid key image is found:
    • The boot loader decrypts the incoming data stream using AES decryption with a 256-bit key before programming the data.
    • The incoming image should consist of a full flash image starting at address 0x4000, with the 16 bytes at the end of flash containing the authentication signature.
      • The flash end address, APP_END, is defined in the header file linker_defines.h. This file is used by the key creation project and the boot loader project. The flash application end address can be defined smaller than the actual flash end to reduce the time to update a device, but once defined in the boot loader, that becomes the maximum size of the image that can be uploaded into that device.
    • The boot loader computes an AES-CBCMAC signature on the data from address 0x4000 to the end of flash minus 16 bytes.
    • If that signature matches the one stored at the end of flash, the boot loader hides the EEPROM blocks that contain the keys and jumps to the application code.
Tip: A method to change the encryption keys would be to add a new function that can revoke the current key using a valid hash with the current key and a specific command.