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

2.5 Running the Shared Key Serial Boot Loader

While the boot loader could be programmed in a non-secure environment, that would open up a risk that the initialization vectors could be exposed. Therefore, the best method is to program the boot loader and the keys simultaneously in a secure environment. When the boot loader is programmed in the first sector, and an image of the keys is programmed in the sector at APP_BASE, the boot loader copies the keys into EEPROM and then erase the sector at APP_BASE. If the “Release” configuration is used, the boot loader then write protects itself and disables JTAG.

The “Debug” configuration of the boot loader should not be released in the field. Without much difficulty someone can connect to the JTAG port with an emulator and write code that would expose the keys. Then they could make their own programs that would load using these keys.

The user should consider whether or not to expose the JTAG pins on their circuit board. It is possible to program the initial boot loader and the keys using the ROM boot loader. Therefore, JTAG access is not required. Using the “Release” configuration of the boot loader disables the JTAG interface, but someone could still use the method of recovering a locked microcontroller to completely reset the device. This would erase the boot loader, the application code, and the keys which were in EEPROM. Afterwards, they could then program their own code into that device. It would be the same effect as if they desoldered the TM4C device and replaced it with a new one. For ball grid array (BGA) devices, JTAG can be hidden by not adding traces to the JTAG balls. For quad flat pack (QFP) devices the pins are exposed even if there are no traces to the pins.

The main disadvantage of not having access to the JTAG pins is that the device cannot be recovered externally. Therefore, the user must ensure there is a validated process to re-enter the boot loader. Also, it would not be possible to do analysis of failing parts without removing them from the printed circuit board.