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.

Place a portion of .text in different memory areas?

Guru 15580 points

The Compiler user guide says "The.text section contains all the executable code." Is it possible to place certain selected portions of the executable .text code in different named memory areas? I would like to keep certain functions in an area of memory that I can use for temporary storage during a firmware upgrade process. The other functions would need to continue to run normally during the firmware upgrade. Since the DSP will experience a power-on reset after the upgrade this should alleviate any potential scrambled code.

  • Here is how to put one specific function in a particular memory range.  First, compile with the option the option --gen_func_subsections.  This causes each function to be placed in a section named .text:name_of_function.  (If you are using the older COFF ABI, then the section is named .text:_name_of_function.  Note the leading underscore.)  Then, in the SECTIONS directive of your link command file, you can write something like ...

        .text:name_of_function > SPECIAL_MEMORY

    This creates an output section named .text:name_of_function.  It contains one input section which has the same name.  Replace SPECIAL_MEMORY with name of the memory range you need.

    Alternatively, if you want to allocate all of the functions from one file, you can write ...

        special_output_section { file.obj(.text) } > SPECIAL_MEMORY

    This creates an output section named special_output_section.  Its input section is the .text section (or possibly all the .text:something input sections) from file.obj.  

    Thanks and regards,

    -George

  • Yes it is possible. Just google a bit. This is what I have found: http://ext02.fh-kaernten.at/rts/intern/downloads/DSP/iw6000%20Chapter%203.pdf

    You did not specify what device you are using but for most cases you will have to create appropriate sections in the linker file and use a few pragmas in your c code. 

    http://processors.wiki.ti.com/index.php/Pragmas_You_Can_Understand

    Regards,
    Maciej

  • Thanks Maciej. Unfortunately, this is all DSP/BIOS oriented.

  • Thanks George. Perfect!

  • I am now trying to place an entire .lib into a special memory section. I am trying the following syntax, but get a linker error:

    special_section_name {entire_library.lib} >  MEMORY_SECTION

    I have included a link to the entire_lirbary.lib in the File Search section of CCS, but I get an error message saying that CCS can't find the file. I prefer not to include an absolute file path in my linker file. What am I doing wrong?

  • Change it to this ...

        special_section_name {-lentire_library.lib } > SPECIAL_MEMORY /* Note -l */

    However, I suspect this will cause other problems.  Based on your other posts, I presume you are building for a C5500 device.  When I do something similar with rts55.lib, I get lots of linker diagnostics like this ...

    error: cannot place data input section
    "C:\ti_ccs55\ccsv5\tools\compiler\c5500_4.4.1\lib\rts55.lib<ctype.obj>(.const:__ctypes_)" in text output section ".all_rts"

    Because of the difference in how code and data is addressed, you cannot combine code and data in the same section.

    Thanks and regards,

    -George

  • George,

    Yes, C5515.

    Thanks for the suggestion. I added the -l as you suggested, but the linker still can't find the path unless I include the absolute path name at the top of the .cmd file (-l "C:\Users\Mike\Documents\TI Workspaces\MyProject\Lib\entire_library.lib").

  • Is this directory ...

    MikeH said:
    "C:\Users\Mike\Documents\TI Workspaces\MyProject\Lib\entire_library.lib"

    listed among the -i (or might be --search_path) options in the linker invocation?

    Thanks and regards,

    -George

  • The .lib was -l directly in CCS, but the search path -i was not. After adding the proper search path, the linker works properly.

    Seems like -l should give enough path info without having to include the -i also.

    Thanks for your help.