SPRAAU8A March 2008 – August 2017 TMS320F2801 , TMS320F2801 , TMS320F2801-Q1 , TMS320F2801-Q1 , TMS320F28015 , TMS320F28015 , TMS320F28016 , TMS320F28016 , TMS320F28016-Q1 , TMS320F28016-Q1 , TMS320F2802 , TMS320F2802 , TMS320F2802-Q1 , TMS320F2802-Q1 , TMS320F28044 , TMS320F28044 , TMS320F2806 , TMS320F2806 , TMS320F2806-Q1 , TMS320F2806-Q1 , TMS320F28062 , TMS320F28062 , TMS320F28062-Q1 , TMS320F28062-Q1 , TMS320F28062F , TMS320F28062F , TMS320F28062F-Q1 , TMS320F28062F-Q1 , TMS320F28063 , TMS320F28063 , TMS320F28064 , TMS320F28064 , TMS320F28065 , TMS320F28065 , TMS320F28066 , TMS320F28066 , TMS320F28066-Q1 , TMS320F28066-Q1 , TMS320F28067 , TMS320F28067 , TMS320F28067-Q1 , TMS320F28067-Q1 , TMS320F28068F , TMS320F28068F , TMS320F28068M , TMS320F28068M , TMS320F28069 , TMS320F28069 , TMS320F28069-Q1 , TMS320F28069-Q1 , TMS320F28069F , TMS320F28069F , TMS320F28069F-Q1 , TMS320F28069F-Q1 , TMS320F28069M , TMS320F28069M , TMS320F28069M-Q1 , TMS320F28069M-Q1 , TMS320F2808 , TMS320F2808 , TMS320F2808-Q1 , TMS320F2808-Q1 , TMS320F2809 , TMS320F2809 , TMS320F2810 , TMS320F2810 , TMS320F2810-Q1 , TMS320F2810-Q1 , TMS320F2811 , TMS320F2811 , TMS320F2811-Q1 , TMS320F2811-Q1 , TMS320F2812 , TMS320F2812 , TMS320F2812-Q1 , TMS320F2812-Q1 , TMS320F28232 , TMS320F28232 , TMS320F28232-Q1 , TMS320F28232-Q1 , TMS320F28234 , TMS320F28234 , TMS320F28234-Q1 , TMS320F28234-Q1 , TMS320F28235 , TMS320F28235 , TMS320F28235-Q1 , TMS320F28235-Q1 , TMS320F28332 , TMS320F28332 , TMS320F28333 , TMS320F28333 , TMS320F28334 , TMS320F28334 , TMS320F28335 , TMS320F28335 , TMS320F28335-Q1 , TMS320F28335-Q1
This application report and associated code files provide functionality for copying initialized compiler sections from the internal Flash memory to the internal random access memory (RAM) of the TMS320F28xxx digital signal controllers (DSCs) at run time for optimizing execution speed. The solution provided implements this functionality directly after booting before entering the c_int00 C entry routine.
Project collateral and source code discussed in this application report can be downloaded from the following URL: http://www.ti.com/lit/zip/spraau8.
C2000, C28x, DSP/BIOS, Code Composer Studio, TMS320C2000 are trademarks of Texas Instruments.
eZdsp is a trademark of Spectrum DIgital, Inc.
All other trademarks are the property of their respective owners.
In many applications, code execution speed is critical to the end application. A few examples of time critical end equipment would be medical, motion control, motor control, etc. Many of these applications use the TMS320F28xxx DSCs due to its internal Flash memory. The internal Flash memory is a great benefit of the TMS320F28xxx family because it is non volatile memory that allows designers to store application code internal to the chip as opposed to interfacing external memory to store this code. The downside of using the internal Flash is that wait states are required to access the flash, which leads to slower code execution time. In most applications this is not an issue. Other applications may require zero wait-states for maximum speed. The internal RAM memory has zero wait-states but is a volatile memory. As a result, initialized sections cannot be stored on this memory for boot up.
The solution presented allows designers to copy initialized compiler sections (.text, .cinit, .econst, .switch, etc.) from the Flash to RAM at runtime to allow maximum execution speed. This gives code execution a boost from up to 15 wait-states to 0 wait-states. For another solution on copying just certain functions from Flash to RAM, see Running an Application from Internal Flash Memory on the TMS320F28xx DSP (SPRA958). This implementation should be used in most C2000™ DSC applications. Other applications requiring tight timing with continuous zero wait-states should implement this presented solution.
An assembly routine was written to perform the copy from Flash to RAM. This assembly code is executed after the reset vector before the call to c_int00. This ensures that the sections are copied before c_int00 calls main().
Some projects are small enough that all of the initialized sections can be copied to RAM. Other projects, however, have initialized sections that are larger than the max 18K of internal RAM for TMS320F281x/TMS320F280xx DSCs and 34K for TMS320F2833x DSCs. These projects may not be able to copy all initialized sections to RAM but could use this solution to copy some of the sections.
It is assumed that Running an Application from Internal Flash Memory on the TMS320F28xx DSP (SPRA958) has been viewed and its methodologies are followed for Flash implementation.
The compiler creates multiple portions of code and data called sections. These sections are categorized into two different groups: initialized and uninitialized. The initialized group of sections is composed of all code, constants, and initialization tables. Table 1 shows the initialized sections produced by the compiler.
Name | Contents | Restrictions |
---|---|---|
.cinit | Tables for explicitly initialized global and static variables | Program |
.const | Global and static const variables that are explicitly initialized and string literals | Low 64K data |
.econst | Far constant variables | Anywhere in data |
.pinit | Tables for global object constructors | Program |
.switch | Tables for implementing switch statements | Program (with -mt option)
Data (without -mt option) |
.text | Executable code and constants | Program |
The uninitialized group of sections is composed of variables, the stack, and malloc memory. Table 2 shows the uninitialized sections produced by the compiler.
Name | Contents | Restrictions |
---|---|---|
.bss | Global and static variables | Low 64K data |
.ebss | Far global/static variables | Anywhere in data |
.stack | Stack space | Low 64K data |
.sysmem | Memory for malloc functions | Low 64K data |
.esysmem | Memory for far_malloc functions | Anywhere in data |
Once the compiler has generated these sections the linker takes the individual sections from each source file and combines them to create an output section. The linker command file (.cmd) is used to tell the linker where to allocate these sections. Initialized sections must be assigned to a non volatile memory like Flash/ROM so the application is not erased when power is removed from the target. Uninitialized sections can be allocated to RAM as they are initialized during code execution.
For more information regarding compiler sections and linking, see the TMS320C28x Assembly Language Tools User’s Guide (SPRU513) and the TMS320C28x Optimizing C/C++ Compiler User’s Guide (SPRU514).
Texas Instruments has multiple examples available that show the use of the linker command file to allocate compiler sections. One such example is the Running an Application from Internal Flash Memory on the TMS320F28xx DSP (SPRA958). This application report provides examples that demonstrate the use of the linker command file for both RAM based and Flash based projects.
The C/C++ Header Files and Peripheral Examples for each C28x™ DSP generation also provides examples for RAM and Flash based examples. For more information, see C281x C/C++ Header Files and Peripheral Examples (SPRC097), C280x, C2801x C/C++ Header Files and Peripheral Examples Software Tools (SPRC191), and C2833x/C2823x C/C++ Header Files and Peripheral Examples Application Software (SPRC530).