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.1 Flash API

Flash operations on all C2000 operations are performed by the CPU. Algorithms are loaded into RAM and executed by the CPU to perform any Flash operations. For instance, erasing or programming the Flash of a C2000 device with CCS entails loading Flash algorithms into the RAM over JTAG and having the CPU execute them.

All Flash operations are performed using the Flash Application Programming Interface (API); the device-specific library and reference guide is available in C2000Ware [3] at “libraries/flash_api”. Applications that require erase or program Flash at runtime can link the Flash API library to perform Flash programming.

However, applications that call the Flash API are not advised to execute from the same Flash bank, since erasing or programming the Flash while also executing code introduces race conditions and undefined behavior. Hence, the Flash API needs to be executed from the RAM or another Flash bank (if additional banks exists for the same core).

This can be achieved by allocating the Flash API to the “.ti.ramfunc” section in the linker command file, designating a Flash load address and RAM run address, and then copying the functions to RAM in the main function before executing. Comprehensive details on Flash programming on C2000 devices can be referenced in [4] and [5].

Note: On multicore devices, one CPU cannot access another CPU's allocated Flash bank. For instance, the Flash bank of the CPU2can only be programmed by executing the Flash API from CPU2 RAM.