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.

output section warnings

I keep gettings the followings warnings when linking my application.

>> warning: creating output section bootloader without SECTIONS specification
>> warning: creating output section pcm_data_buf without SECTIONS specification
>> warning: creating output section sram without SECTIONS specification
>> warning: creating output section saram without SECTIONS specification
>> warning: creating output section daram without SECTIONS specification
>> warning: bootloader section (0x3ef90) spans page boundary: not allowed before

I am not sure how to get rid of these warning. I have read the C5505 compiler and assembler user's manuals but have not come up

with a solution. I am using C/C++ and not asssembly lanuage.

Thanks

Barry

 

  • Hi Barry,

    These linker warnings stem from the fact that the linker has encountered a compiled section (e.g. 'bootloader') but it has not been told where to place these sections. The 55x Compiler guide discusses this a bit in sections 4.3.6 and 4.3.7.

    Basically, you need to tell the linker via a linker command file where to place those sections into memory. As an example, your command file might look like this:

    MEMORY
    {
    /* Memory Map declarations */
    }

    SECTIONS
    {
    /* Existing SECTION declarations*/
    bootloader > BOOTLOAD_MEMORY
    pcm_data_buf > DARAM
    sram > EXTERNAL_SRAM
    saram > SARAM
    daram > DARAM
    /* etc */
    }

    Note that if you are using DSP/BIOS that all of the sections generated by the C Compiler can be placed in the .tcf file, and you - the user - are only responsible for custom code/data sections.

  • Tim

    “bootloader”  is defined as follows:

     

    #pragma DATA_SECTION(aulData, "bootloader");

    static UINT32 aulData[NUM_ADC_BUFFERS * SIZE_OF_OSR_STORE_MAX];

     

    void ProcessADC(void)

     

    I am using DSP/BIOS and have defined bootloader as memory section with a base and length. The other warnings are for memory sections (except for pcm_data_buf) that are defined in memory section of DSP/BIOS as well. The other sections represent the memory that is on the 5505 chip and some off chip SRAM memory. I have divided the SRAM memory into a SRAM section and a bootloader section.

    Thanks

    Barry

     

  • Barry,

    I think the confusion stems from the difference between a memory SEGMENT and a memory SECTION. A memory section is a group of symbols whereas a segment defines a range of physical memory. In other words, you place a section into a segment. The linker is not smart enough to automatically associate these two together, so this must be done explicitly by the user (or by BIOS for compiler-generated sections). When using the DATA_SECTION or CODE_SECTION pragmas the user is always responsible for associating a section into a segment.

  • Tim,

    I am using DSP/BIOS and have defined sram, saram, daram, and bootloader as memory sections in their graphical interface. "bootloader" is also used as a memory section name in th #pragma command. I received the following  from a previous post.

     

    You can allocate buffers in a specific memory section using  #pragma as shown below.

    #pragma DATA_SECTION(bufferName, "memorySectionName");

    Pratap Reddy.

    In any case all the defined memory sections defined in DSP/BIOS return the same warning message. I have got to be missing something somewhere.

    Thanks

    Barry

  • Barry,

    Forgive me for repeating myself, but I think you are still confusing memory segments with memory sections. I really wish different names were picked for these things! Let me try to clarify my previous post a bit more.

    Your #pragma statements are creating data and code sections. The compiler uses these sections to group up similar code which the linker will then later allocate into a memory segment (which is a representation of physical memory).

    When you go into your .tcf file and add stuff to the MEM - Memory Section Manager you are actually defining what I call memory segments, NOT sections. This is the equivalent of the MEMORY directive used in the linker command file. The MEMORY directive is actually discussed in section 8.8 of the 55x Assembly Guide.

    Once the memory segments are defined in the BIOS .tcf file or the linker.cmd file (if done by hand) then the linker can then associate the data/code sections into those memory segments. This was discussed in sections 4.3.6 and 4.3.7 of the Compiler Guide as I mentioned in my last post.

    Do these differences make sense? The big thing to note is that a #pragma DATA_SECTION or CODE_SECTION section name is completely independent of a memory range defined in your .tcf file. The linker will make no assumptions that you want that data/code section placed in the similarly named memory segment, so you still must do this by hand in your linker.cmd file.

  • Tim,

    I understand what your saying about memory segments and memory sections.If you are using DSP/BIOS what do you use to setup the memory sections in the memory segments. I used the Memory Section manager to setup the memory segments. The DSP_BIOS_5505...cmd files says not to modify it. I did inherit this source code without inheriting any of the pjt,tcf,cmd, or any other files or documentation. I did find some other #pragma commands I did not know were there. One of them points to the fifo of an external device. I do appreciate any help I get.

    Thanks

    Barry

  • Barry,

    Barry Turner said:
    The DSP_BIOS_5505...cmd files says not to modify it.
    Easy enough to get around! Just create a new source file and call it linker.cmd or something to that effect. Then add in the appropriate declarations in a SECTIONS directive. It will look something like this:

    -l bioscfg.cmd /* The file automatically generated by BIOS */

    SECTIONS{
    /* Section name*/ saram > SARAM /* Segment name as defined in your BIOS .tcf file */
    bootloader > BOOTLOADER
    /* etc... */
    }
    You may need to exclude the original bioscfg.cmd (your BIOS-generated file will have a different name) from the build process by right clicking on the file in the file listing. We can go over that if you have troubles getting there. Let me know how the adding the custom linker.cmd file goes.

  • Tim,

    It will be Monday before I tacke this but I will let you know what happens.

    Thanks

    Barry

  • Tim

    I have created a linker .cmd file and got rid of the warning for the sections I put in the structure in the cmd file. I am now trying to determine how large the bootloader section needs to be and where it needs to be. I have one other section that is used in a #pragma statement that I need to determine where it should be and how large as well. I do not think the bootloader section has anything to do with the bootloader but am not sure. It appears to contains buffers that ADC data is stored. The comments in the code indicate that the other section may point to a FIFO in a device. I still have to find out how to initialize (what values to put in the control registers) the control registers in the EMIF so I can access my SRAM correctly. Thanks for the help.

    Barry

     

  • Can I just clarify something?

    Using DSP/BIOS, if I do make a custom data section, e.g. as in the following:

    #pragma DATA_ALIGN (data_br_buf, FFT_ALIGN);

    #pragma DATA_SECTION(data_br_buf, "data_br_buf");

    Int32 data_br_buf[N_FFT_POINTS];

    Do I simply need to make additions to my .tcf file or must I handle it somewhere else?

  • I have now tried creating the linker.cmd file and have come across problems with things being redeclared - whether or not I exclude the cmd file generated in the debug folder as when you rebuild the folder it seems to recreate the file thus superceding it being excluded...

    Any ideas?

     

    EDIT : apparently I can fix it by not including the first line ( -l bioscfg.cmd ), the extra file still has the desired effect, but without duplicating the cmd file.