• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 748 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320F28379D: Minimum changes to run code from flash memory in the linker command file?

Graham Reitz29
Intellectual 960 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Tool/software: Code Composer Studio

What are the minimum changes needed to execute code from flash? (no reading/writing data from the executing code to/from flash)

In the flash_programming_cpu examples the linker command file has the following:

#ifdef __TI_COMPILER_VERSION__
    #if __TI_COMPILER_VERSION__ >= 15009000
        GROUP
        {
            .TI.ramfunc
            { -l F021_API_F2837xD_FPU32.lib}
         
        } LOAD = FLASHD,
          RUN  = RAMLS03, 
          LOAD_START(_RamfuncsLoadStart),
          LOAD_SIZE(_RamfuncsLoadSize),
          LOAD_END(_RamfuncsLoadEnd),
          RUN_START(_RamfuncsRunStart),
          RUN_SIZE(_RamfuncsRunSize),
          RUN_END(_RamfuncsRunEnd),
          PAGE = 0

Q1) Is it necessary to load F021_API_F2837xD_FPU32.lib if code is only executing from flash versus the code actively reading/writing data from the code to flash?

Q2) What else besides updating the MEMORY and SECTION areas to map the flash memory is required?

Kindly,

Graham

  • 0
    Guru 30330 points
    Graham,

    This question is asked quite often and answered on the forum. Please search before posting in the future.

    We have this app note documenting the process. there are minor differences since the appnote was released - ".TI.ramfunc" used to be just "ramfuncs": http://www.ti.com/lit/spra958

    You can also look at the F28379D Workshops and find that the first few chapters cover the linker file and then loading and executing code from the internal flash memory : processors.wiki.ti.com/.../C2000_Multi-Day_Workshop

    Q1) No, it is not necessary to include the FLASH API library if you are not going to be actively writing to the Flash memory during your application.
    Q2) Please see the app note and shop linked above.

    Regards,
    Mark
  • 0 in reply to Mark Labbato
    Intellectual 960 points

    Hi Mark,

    I had read through the material you posted.  Though the Application Report seems a little dated.

    I have code that ran fine when no flash memory was in use.  With the new linker command file that utilizes flash memory the code complies and links without error.   Though it doesn't run when it's in use.

    It's hard to tell what I've missed.   Below is the new linker command file.  Did I miss something?

    MEMORY
{

PAGE 0 :    // Program memory

    // BEGIN is the start address for user code
    BEGIN:      origin = 0x080000, length = 0x000002

    // RAMMx is MCU dedicated, 1024 bytes each, 2048 total
    RAMM0:      origin = 0x000122, length = 0x0002DE

    // 128 bytes
    CPUxCLA1toCPUxMSGRAM:   origin = 0x001480, length = 0x000080

    // 128 bytes
    CPUxtoCPUxCLA1MSGRAM:   origin = 0x001500, length = 0x000080

    // 512 bytes
    UPPTXMSGRAM:            origin = 0x006C00, length = 0x000200

    // 512 bytes
    UPPRXMSGRAM:            origin = 0x006E00, length = 0x000200

    // Local shared RAM, 2048 bytes each, 12288 total
    RAMLS0:     origin = 0x008000, length = 0x000800
    RAMLS1:     origin = 0x008800, length = 0x000800
    RAMLS2:     origin = 0x009000, length = 0x000800
    RAMLS3:     origin = 0x009800, length = 0x000800
    RAMLS4:     origin = 0x00A000, length = 0x000800
    RAMLS5:     origin = 0x00A800, length = 0x000800

    // RAMDx is MCU dedicated, 2048 bytes each, 4096 total
    RAMD0:  origin = 0x00B000, length = 0x000800
    RAMD1:  origin = 0x00B800, length = 0x000800

    // RAMGSn Globaly shared between MCUs, 4096 bytes each, 53,248 total
    RAMGS0:     origin = 0x00C000, length = 0x001000
    RAMGS3:     origin = 0x00F000, length = 0x001000
    RAMGS4:     origin = 0x010000, length = 0x001000
    RAMGS5:     origin = 0x011000, length = 0x001000
    RAMGS6:     origin = 0x012000, length = 0x001000
    RAMGS7:     origin = 0x013000, length = 0x001000
    RAMGS8:     origin = 0x014000, length = 0x001000
    RAMGS9:     origin = 0x015000, length = 0x001000
    RAMGS10:    origin = 0x016000, length = 0x001000
    RAMGS11:    origin = 0x017000, length = 0x001000
    RAMGS12:    origin = 0x018000, length = 0x001000
    RAMGS13:    origin = 0x019000, length = 0x001000
    RAMGS14:    origin = 0x01A000, length = 0x001000
    RAMGS15:    origin = 0x01B000, length = 0x001000

    // FLASHn, 8192 or 32,768 bytes each
    FLASHA:     origin = 0x080002, length = 0x001FFE  // 8,192 bytes
    FLASHB:     origin = 0x082000, length = 0x002000  // 8,192 bytes
    FLASHC:     origin = 0x084000, length = 0x002000  // 8,192 bytes
    FLASHD:     origin = 0x086000, length = 0x002000  // 8,192 bytes

    FLASHEtoJ:  origin = 0x088000, length = 0x030000  // 196,608 bytes

    FLASHK:     origin = 0x0B8000, length = 0x002000  // 8,192 bytes
    FLASHL:     origin = 0x0BA000, length = 0x002000  // 8,192 bytes
    FLASHM:     origin = 0x0BC000, length = 0x002000  // 8,192 bytes
    FLASHN:     origin = 0x0BE000, length = 0x002000  // 8,192 bytes

    // Reset
    RESET:		origin = 0x3FFFC0, length = 0x000002

PAGE 1 :    // Data memory

    // RAMMx is MCU dedicated, 1024 bytes each, 2048 total
    RAMM1:      origin = 0x000400, length = 0x000400

    // RAMGSn Globaly shared between MCUs, 4096 bytes each, 53,248 total
    RAMGS1      : origin = 0x00D000, length = 0x001000
    RAMGS2      : origin = 0x00E000, length = 0x001000

    // MCU shared, 1024 bytes each, 2048 total
    CPU2TOCPU1RAM:  origin = 0x03F800, length = 0x000400
    CPU1TOCPU2RAM:  origin = 0x03FC00, length = 0x000400
}

SECTIONS
{
    // Code start entry point
    codestart:		> BEGIN, PAGE = 0

    // Initialized C global variables at startup
    .cinit:			> FLASHA, PAGE = 0

    // Stdio buffer
    .cio:			> RAMGS0, PAGE = 0

    // Reset
    .reset:			> RESET, PAGE = 0, TYPE = DSECT	// not used

    // Jump tables for switch statements
    .switch:        > FLASHA, PAGE = 0

    // Executable code
    .text: >> FLASHEtoJ, PAGE = 0

    // Reserve space for unintialized variables
    .ebss:			> RAMGS1, PAGE = 1

    // Initialized const objects
    .econst:		> FLASHA, PAGE = 0

    // Dynamic memory allocation
    .esysmem:		> RAMGS2, PAGE = 1

    // Function call stack, cio (printf) requires a larger stack
    .stack:			> RAMM1, PAGE = 1

#ifdef __TI_COMPILER_VERSION__
    #if __TI_COMPILER_VERSION__ >= 15009000
    .TI.ramfunc
    LOAD = FLASHA,
    RUN = RAMLS0,
    PAGE = 0
   #else
    ramfuncs:  > RAMM0, PAGE = 0
   #endif
#endif

}

    I suspect the repeated questions on this topic are due to the method the documentation presents it.  The required material is typically available in the documentation but it's presented in a way that can be challenging for engineers unfamiliar with TI MCUs.

    Kindly,

    Graham

  • 0 in reply to Graham Reitz29
    Guru 30330 points
    Graham,

    Yes the appnote is dated, but the content is still correct. Though it references older devices, and old tools, the changes to make to your application are unchanged. The workshop also provides step by step building of a RAM based program with the eventual transition to booting from flash.

    Your linker file is not complete.

    Please look at the linker file provided in c2000ware: \C2000Ware_1_00_06_00\device_support\f2837xd\common\cmd\2837xD_FLASH_lnk_cpu1.cmd

    All of the F2837xD examples include a Flash and a RAM build configuration. The "_FLASH" is added to the Predefined symbols list, allowing different code to execute, like the memcpy() function which moves functions defined in .TI.ramfunc to be moved to the proper RAM location to execute. It will also pull in a Flash linker file with the proper configuration - which you can then edit as needed.
    Perhaps the simplest example to look at would be the blinky example, then under the Project properties, select the active build configuration to be "CPU_FLASH".

    -Mark
  • 0 in reply to Mark Labbato
    Intellectual 960 points
    Thanks Mark,

    I was able to get it working and answer my original question. What mades this effort confusing was the code in the examples, labs, and documentation that is no longer necessary.

    Kindly,
    Graham