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
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.