Post Go back to editing

How to declare the data buffer placement in L2 memory of ADSP21562?


I lose time serching how to do that in C source file (CCES 2.10.1).

Where I can find description of memory declaration for C variables?

Best regards,


  • Hi Roman,

    Every DSP project requires one Linker Description File (.ldf). The .ldf file specifies precisely how to link projects. The Linker chapter describes the linking process and how the .ldf file ties into the linking process.

    The default memory sections and mappings are available in the 'app.ldf' which is available in the project directory ../system/startup_ldf/app.ldf

    You can find the "app.ldf" of your project in the below path of the project explorer view for more details:
    Project > system > startup_ldf > app.ldf

    Please refer the below CCES help path for more details on ldf file and linking process.
    CrossCore® Embedded Studio 2.10.1 > SHARC® Development Tools Documentation > Linker and Utilities Manual > Linker Description File

    The data memory data section(seg_dmda), is where the compiler puts global and static data. When linking, your .ldf file is used to map this section to DM space.

    Therefore, By default when linking data using .ldf file, linker resides data in seg_dmda input section that already defined in default ldf file.

    Controlling the placement of the function or data is then a case of adding appropriate output section in LDF.

    You can use #pragma section("section_name") directive to force your data into specific memory. Use this before each function that you want to place in the section.This pragma will only affect the next symbol and if you use this pragma right before a function, that function alone will be placed in the section.

    For example:

    #pragma section ("seg_test") //custom_section_name
    int testbuffer[25];

    Also, add the appropriate INPUT_SECTIONS commands to your LDF in a suitable place in app.ldf, like below.

    custom_section_name //Output section
    INPUT_SECTIONS( $OBJS_LIBS(custom_section_name) ) // Input section
    } > > mem_section_name // Memory section

    For eg:

    INPUT_SECTIONS( $OBJS_LIBS(seg_test) )
    } > MY_L2_CACHED_MEM

    We have tried mapping data buffer into L2 memory using #pragma section("section_name") directive. Please refer the attached screenshots for your reference.

    For more information, take a look at the "#pragma section/#pragma default_section" in the CCES help:
    CrossCore® Embedded Studio 2.10.1 > SHARC® Development Tools Documentation > C/C++ Compiler Manual for SHARC® Processors > Compiler > C/C++ Compiler Language Extensions > Pragmas > Linking Control Pragmas > #pragma section/#pragma default_section

    Also, By enabling the 'Generate symbol Map' option under the 'General' options for the Linker. If you enabled the option to "Generate Symbol Map", the Linker will also generated a file which can be viewed in Internet Explorer to view a map of your project. It shows the memory sections declared in the LDF, their start and end bounds and - most importantly - their free/used space. Using this map file you can determine whether there is perhaps a memory section that is being under-used that you could place more data into.


  • Dear Santhakumari.K,

    many, many thanks for effective help ! Grinning

    Best regards,


  • Dear Santhakumari.K,

    still have a problem.

    1. Must access L2 memory as 32-bit DM(0x08030000–0x0803FFFF area), and my additions to app.ldf file don't work:

       mem_L2_dw               { TYPE(DM RAM) START(0x08030000) END(0x08037FFF) WIDTH(32) }
       mem_L2_bw               { TYPE(BW RAM) START(0x200c0000) END(0x200f9fff) WIDTH(8) }
       mem_L2UC_bw             { TYPE(BW RAM) START(0x200fa000) END(0x200fdfff) WIDTH(8) }
       mem_L2BC_bw             { TYPE(BW RAM) START(0x200fe000) END(0x200fffff) WIDTH(8) }


              dxe_test_data DM
            INPUT_SECTIONS( $OBJS_LIBS(seg_test) )
            } > mem_L2_dw

    2. Also 480 nw buffer in L1 has to be 32-bit DM.

    Please, help.


  • The problem seems to be solved with the b2w instruction.