SPRUJH3 April   2025 TMS320F2800132 , TMS320F2800133 , TMS320F2800135 , TMS320F2800137 , TMS320F2800152-Q1 , TMS320F2800153-Q1 , TMS320F2800154-Q1 , TMS320F2800155 , TMS320F2800155-Q1 , TMS320F2800156-Q1 , TMS320F2800157 , TMS320F2800157-Q1 , TMS320F280021 , TMS320F280023 , TMS320F280023C , TMS320F280025 , TMS320F280025C , TMS320F280034 , TMS320F280036-Q1 , TMS320F280036C-Q1 , TMS320F280037 , TMS320F280037C , TMS320F280038-Q1 , TMS320F280038C-Q1 , TMS320F280039 , TMS320F280039C , TMS320F280040-Q1 , TMS320F280040C-Q1 , TMS320F280041 , TMS320F280041C , TMS320F280045 , TMS320F280048-Q1 , TMS320F280048C-Q1 , TMS320F280049 , TMS320F280049C , TMS320F28076 , TMS320F28374D , TMS320F28374S , TMS320F28375D , TMS320F28375S , TMS320F28376D , TMS320F28376S , TMS320F28377D , TMS320F28377S , TMS320F28378D , TMS320F28378S , TMS320F28379D , TMS320F28379S , TMS320F28384D , TMS320F28384S , TMS320F28386D , TMS320F28386S , TMS320F28388D , TMS320F28388S , TMS320F28P550SG , TMS320F28P550SJ , TMS320F28P559SG-Q1 , TMS320F28P559SJ-Q1 , TMS320F28P650DH , TMS320F28P650DK , TMS320F28P650SH , TMS320F28P650SK , TMS320F28P659DH-Q1 , TMS320F28P659DK-Q1 , TMS320F28P659SH-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
  5. 2Configuring the Boot Mode
    1. 2.1 Standalone Boot
      1. 2.1.1 Boot Mode Select Pins (BMSP)
      2. 2.1.2 Boot Definition Table (BOOTDEF)
      3. 2.1.3 Boot ROM OTP Configuration Registers
      4. 2.1.4 CPU2 Boot Flow
    2. 2.2 Emulation Boot
  6. 3Programming the Flash
    1. 3.1 Flash API
    2. 3.2 Flash Kernels
  7. 4Bootloading Code to Flash
    1. 4.1 C2000 Hex Utility
    2. 4.2 Common Boot Modes
      1. 4.2.1 Boot to Flash
      2. 4.2.2 SCI Boot
      3. 4.2.3 CAN Boot
      4. 4.2.4 CAN-FD Boot
      5. 4.2.5 USB Boot
  8. 5FAQ
    1. 5.1 Selecting the BMSP GPIOs with a Software-based Implementation
    2. 5.2 Running a Flash Kernel from the Flash Instead of the RAM
    3. 5.3 No Symbols Defined When Debugging Boot ROM
    4. 5.4 Writing Values in the OTP Using the On-Chip Flash Tool
    5. 5.5 Writing Values in the OTP Using the Flash API Plugin
  9. 6Summary
  10. 7References

3.2 Flash Kernels

Given that the bootloaders in the boot ROM can only load code into RAM, flash kernels serve as a link between the ROM and flash by providing a mechanism for flash-based firmware upgrades in the field over various communication protocols (SCI, CAN, I2C, and so forth.). Programming the flash can be achieved by using the ROM bootloader to download the flash kernel to RAM, and then running the flash kernel in the RAM to download the application to the flash using the Flash API.

Before any application data is received, the flash kernel erases the flash of the device to prepare for programming. Once the host starts sending the application code, a buffer is used to hold the received contiguous blocks of application code. When the buffer is full or a new block of non-contiguous data is detected, the code in the buffer is programmed. After the entire application is received and programmed to flash, the flash kernel branches to the entry point of the application.

TI has developed flash kernels to load code from the RAM to the flash based on the boot ROM source code, and can be found in the examples folder of C2000Ware. A similar development flow can be applied by the user to implement a custom bootloader for a specific application. The boot ROM source code used by device boot flow, including the peripheral bootloaders, can be viewed in C2000Ware at:

  • C2000Ware_x_xx_xx_xx > libraries > boot_rom > DEVICE_FAMILY > REV# > rom_sources > DEVICE_FAMILY_ROM > bootROM > source

On devices with multiple flash banks, the flash kernel projects can be adapted to execute from the flash instead of the RAM to program another flash bank. This allows users to simply jump to the flash kernel located in the flash and avoid using the bootloaders in the boot ROM. For more details on how to implement this, refer to Section 5.2.

Note:

On multicore devices (that is, F2838x, F2837xD, or F28P65x), CPU1 and CPU2 kernel projects can utilize the bootloader in CPU1 to download a modified bootloader (that is, flash kernel) for CPU2 to download the CPU2 application image.

Once CPU1 operations are completed, CPU1 can write the CPU2 kernel into shared message RAM (CPU1TOCPU2MSGRAM) with an instruction for CPU2 to branch to the CPU2 entry point in the CPU2 IPC message copy destination RAM (M1RAM) during the CPU2 boot sequence. After the branch instruction is written to M1RAM and the CPU2 boot sequence is complete, CPU2 starts execution from M1RAM and branches to CPU2 kernel entry point. The CPU1 kernel is waiting for the CPU2 kernel commands to finish before proceeding.

Please refer to the device-specific technical reference manual for more details on IPC protocol.

All in all, the general flow for using a flash kernel is follows:

  1. Reset the device and use the intended boot mode
  2. Transfer the flash kernel from the host to the device via the bootloader in the boot ROM
  3. The flash kernel takes control after the ROM bootloader is complete
  4. The kernel erases the old application code from flash memory on the controller
  5. Kernel configures a connection with host and receive the new application code using the intended peripheral communications protocol
  6. Kernel writes the newly received application code to flash memory and transfers control to the application
  7. Newly received code from host executes