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.

CCSV5 Linker error trying to move code for bootloader

Other Parts Discussed in Thread: SYSBIOS

I am trying to create a sysbios application to load at a base addres of 0x00002000 instead of 0x00000000 so that I can use it with a bootloader application.  I have my own cmd file which specifies the new locations

#define

APP_BASE 0x00002000

#define

RAM_BASE 0x20000000

--retain=g_pfnVectors

MEMORY

{

// This is where our application can start

FLASH (RX) : origin = 0x00002000, length = 0x0007E000

SRAM (RWX) : origin = 0x20000000, length = 0x00018000

}

SECTIONS

{

// Vectors are at start of FLASH after bootloader

.intvecs: > APP_BASE

.text : > FLASH

.const : > FLASH

.cinit : > FLASH

.pinit : > FLASH

.init_array : > FLASH

.vtable : > RAM_BASE

.data : > SRAM

.bss : > SRAM

.sysmem : > SRAM

.stack : > SRAM

}

However when I link this clashes with what says it is automatically generated linker.cmd in the Debug/ConfigPkg path of the project.

linker.cmd says

/*

* Do not modify this file; it is automatically generated from the template

* linkcmd.xdt in the ti.platforms.stellaris package and will be overwritten.

*/

If this is automatically generated, how do I move the base address for code and vectors so I can work with a bootloader?

  • Hi,

    I hope you're editing the file/creating a new one and linking it over here right?

    Regards,

    Gautam

  • That's what I am doing with my own linker cmd file.

    But the TIRTOS stuff appears to have generated another command file under the debug directory which conflicts with my editied linker cmd file, even though I have specified for the project to use my linker cmd file as you suggest.

  • Then this shouldn't happen! Very weird. I've edited so many cmd files and they all work fine; I guess there's some issue with the internal settings. Let me check and get back to you...

    Regards,

    Gautam

  • Barry Andrews said:

    However when I link this clashes with what says it is automatically generated linker.cmd in the Debug/ConfigPkg path of the project.

    If this is automatically generated, how do I move the base address for code and vectors so I can work with a bootloader?

    The file linker.cmd is automatically generated for SYS/BIOS projects and cannot be modified. As you can see from the linker.cmd some sections such as .vecs and .resetVecs are being allocated to specific addresses (in this case 0x20000000 and 0x0). These over-ride the .vtable and .intvecs sections specified in the project linker command  (lm3s9d92.cmd or your own custom file). as BIOS is just giving those sections different names.

    If you are OK with leaving interrupt vectors at address 0x0, and just want your app code to begin at 0x2000, then you just need to leave the memory range starting at 0x0 defined in your custom linker command file. So your MEMORY specification would be:

    MEMORY

    {

    FLASH1 (RX): origin = 0x00000000, length = 0x00002000
    FLASH (RX) : origin = 0x00002000, length = 0x0007E000
    SRAM (RWX) : origin = 0x20000000, length = 0x00018000

    }

    This should allow you to link and will place your app code at 0x2000 but leave the interrupt vectors at 0x0.

    If you want the interrupt vectors to also go to 0x2000 along with your app, then you would need to modify your custom linker command file to change the section name from .intvecs to .resetVecs, and load it to 0x2000. I have attached a reference linker command file here (renamed to .txt). 

    /******************************************************************************
     *
     * Default Linker Command file for the Texas Instruments LM3S9D92
     *
     * This is part of revision 10114 of the Stellaris Peripheral Driver Library.
     *
     *****************************************************************************/
    #define APP_BASE 0x00002000
    #define RAM_BASE 0x20000000
    
    --retain=g_pfnVectors
    
    MEMORY
    {
        FLASH1 (RX) : origin = 0x00000000, length = 0x00002000
        FLASH (RX) : origin = 0x00002000, length = 0x0007E000
        SRAM (RWX) : origin = 0x20000000, length = 0x00018000
    }
    
    /* The following command line options are set as part of the CCS project.    */
    /* If you are building using the command line, or for some reason want to    */
    /* define them here, you can uncomment and modify these lines as needed.     */
    /* If you are using CCS for building, it is probably better to make any such */
    /* modifications in your CCS project and leave this file alone.              */
    /*                                                                           */
    /* --heap_size=0                                                             */
    /* --stack_size=256                                                          */
    /* --library=rtsv7M3_T_le_eabi.lib                                           */
    
    /* Section allocation in memory */
    
    SECTIONS
    {
    /*     .intvecs:   > APP_BASE   */
        .resetVecs: load > APP_BASE
        .text   :   > FLASH
        .const  :   > FLASH
        .cinit  :   > FLASH
        .pinit  :   > FLASH
        .init_array : > FLASH
    
        .vtable :   > RAM_BASE
        .data   :   > SRAM
        .bss    :   > SRAM
        .sysmem :   > SRAM
        .stack  :   > SRAM
    
    }
    
    __STACK_TOP = __stack + 512;
    

    A second part of the process would be to make sure that your linker command file is passed to the linker before linker.cmd in the command line so the section allocations are picked up first from your linker command file. To do this, go to Project Properties->Build->Link Order tab, click on Add and select  "Generated Linker Command files" and your linker command file. Then click on your linker command file and move it Up to be earlier on the list.

    In each case, please check the link map file generated to check if sections are being allocated to the expected memory regions.

  • Firstly thanks for the detailed answer, very easy to follow.

    This now gives me the correct map