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.

Compiler/TMS320F28377D: No matching section warning for FlashAPI library file... in bootloader application

Part Number: TMS320F28377D
Other Parts Discussed in Thread: SYSBIOS, TMS320F28377S

Tool/software: TI C/C++ Compiler

Dear Friends,

I am working on flash programming of 377D controller from communication. The command file is modified accordingly, which needs Flash APIs Library files (.obj files) to be copied to RAM. But while building below warning is shown.

"no matching section".

I have checked the file search path in linker properties, which is also OK.

I am stuck at this problem, as the memory is unallocated for those .obj files from the library. Please help.

Thanks in advance,

Raghuchandar.

  • To understand my answer, please read the first half of the wiki article Linker Command File Primer.

    The diagnostic ...

    Raghuchandar Rajula said:
    "no matching section".

    should have a line number associated with it.  It means, for that line of the linker command file, no input sections were found which match the specification.  

    Raghuchandar Rajula said:
    the memory is unallocated for those .obj files from the library.

    Is any code or data from these object files being used anywhere?  Check the map file for occurrences of the name of the library.

    Thanks and regards,

    -George

  • I am also having this issue trying to get the linker to link the flash library into code.
    I am using CCS 6.1.1 with a 28377s
    I have been able to compile and link the example code for the 28377s flash_programming_cpu1 project an view the map file .
    I copied the code from the linker command file for this sample app and I get the same warning of no section and the line number it refers to is the loading of the library.
    The difference is my app is a sysbios app. In the boot section of app.cfg I am specifying the same load and run segments for flash functions as specified below.
    The doco on the linker command files has not shed any light on this as the GROUP is not explained very well.
    Here is the portion of the linker command file that is loading the library and I have marked the line that I get the section error on. This exact same line works in the sample app.
    I appreciate any help I can get resolving this issue.
    Thanks
    Maury

    GROUP
    {
    ramfuncs
    { -l F021_API_F2837xD_FPU32.lib} ***** Warning no section defined

    } LOAD = FLASHD,
    RUN = D01SARAM, **** modified from example to match my flash map
    LOAD_START(_RamfuncsLoadStart),
    LOAD_SIZE(_RamfuncsLoadSize),
    LOAD_END(_RamfuncsLoadEnd),
    RUN_START(_RamfuncsRunStart),
    RUN_SIZE(_RamfuncsRunSize),
    RUN_END(_RamfuncsRunEnd),
    PAGE = 0
  • A GROUP is used when you want to allocate multiple output sections, adjacent to each other, in a particular order. The GROUP you show has only one output section.  So you don't need GROUP.  

    This input section section syntax ...

    maurywalters said:
    { -l F021_API_F2837xD_FPU32.lib}

    ... while legal, is unusual.  It means allocate all of the input sections (.text, .data, and so on) from that library.  It much more likely you mean to write ...

    ramfuncs
    {
       -l F021_API_F2837xD_FPU32.lib(.text)
    } 
    LOAD = FLASHD,
    RUN = D01SARAM,
    LOAD_START(_RamfuncsLoadStart),
    LOAD_SIZE(_RamfuncsLoadSize),
    LOAD_END(_RamfuncsLoadEnd),
    RUN_START(_RamfuncsRunStart),
    RUN_SIZE(_RamfuncsRunSize),
    RUN_END(_RamfuncsRunEnd),
    PAGE = 0

    This says only the .text sections (which contain the code) from the library are allocated in this output section.

    Thanks and regards,

    -George

  • George,
    Thanks I was just copying the flash sample code from the linker command file SECTIONS definition.
    I tried the notation you indicated above and get the same error
    ramfuncs
    {
    -l F021_API_F2837xD_FPU32.lib(.text)
    }
    LOAD = FLASHD,
    RUN = D01SARAM,
    LOAD_START(_RamfuncsLoadStart),
    LOAD_SIZE(_RamfuncsLoadSize),
    LOAD_END(_RamfuncsLoadEnd),
    RUN_START(_RamfuncsRunStart),
    RUN_SIZE(_RamfuncsRunSize),
    RUN_END(_RamfuncsRunEnd),
    PAGE = 0
    I thought maybe we were missing a : after the ramfunc section declaration
    so I added one after ramfuncs and still the same issue
    I saw an example in one of the tools and moved the load library lines to after the ramfuncs section declaration
    but still get the same warning and library does not link.
    ramfuncs :
    LOAD = FLASHD,
    RUN = D01SARAM,
    LOAD_START(_RamfuncsLoadStart),
    LOAD_SIZE(_RamfuncsLoadSize),
    LOAD_END(_RamfuncsLoadEnd),
    RUN_START(_RamfuncsRunStart),
    RUN_SIZE(_RamfuncsRunSize),
    RUN_END(_RamfuncsRunEnd),
    PAGE = 0
    -l F021_API_F2837xD_FPU32.lib(.text)
    }
  • maurywalters said:
    I tried the notation you indicated above and get the same error

    Please show the text of the error.  If it says "no matching section", please see if this forum thread is helpful.

    Thanks and regards,

    -George

  • George,
    The error in the console is the following and the line it is flagging is the one that is trying to load the library
    -l F021_API_F2837xD_FPU32.lib(.text)

    "../TMS320F28377S_NO_APPL.cmd", line 105: warning #10068-D: no matching section

    I looked at the latest link you posted and I tried moving the ramfuncs section before the allocation of other program area sections but get the same warning.
    I see there are a couple syntaxes used in examples and it is not clear what is correct.
    -l F021_API_F2837xD_FPU32.lib(.text)
    -lrts64plus_elf.lib<memcpy64.obj> (.text:memcpy)
    In some cases it is -l with a space and library name others omit the space.
    In some cases the destination is indicated by >( section name)
    What is proper syntax for specifying a memory location not a section when loading a library.

    Note the ramfuncs section works without this load library line as there are some flash init and delay functions that get placed there.

    What I do not understand is that the GROUP syntax worked in a non bios application (the sample flash app) but does not in a sysbios app. That seems to indicate that there is a conflict between the sysbios linker command file and mine. I tried the link order setup but that has not resolved it
    Maury
  • George,
    Maybe I am not understanding exactly what this warning is indicating.
    Is it that there is no section defined in the linker SECTIONS for this library or the section is already used or .....
    In order to understand this better I was trying to just load a different library into some other section not even the ramfuncs section it seems I get the same warning even when I try and just load the library into flash page using the following
    libfuncs : > FLASHD | FLASHE PAGE = 0
    {
    -l F021_API_F2837xD.lib(.text)
    }

    I have the library path and library name specified in the project and also have it specified in the linker file search path and have it set up to be included as a library linker input on this same property page.
    Am I double including the library ?
    I see there are other posts where people are having the same issue but no solutions.
    thanks for the help
    Maury
  • For one of the problem links, please attach the linker command file and map file.  So the forum will accept it, add (not change) the file extension .txt.  For example, file.map changes to file.map.txt.  That should help me understand what happens with the .text sections from the library F021_API_F2837xD.lib.  

    Thanks and regards,

    -George

  • George,

    Ah I forgot I had to rename the command files, now attached and note I have the section linking library commented out.

    The map is attached with that section commented in but it appears it does not link the library in with the warning.

    2313.TMS320F28377S_NO_APPL.txt
    /*
     * Copyright (c) 2014, Texas Instruments Incorporated
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without
     * modification, are permitted provided that the following conditions
     * are met:
     *
     * *  Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     * *  Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the distribution.
     *
     * *  Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
     * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
     * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
     * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
     * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
     * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
     * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
     * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
     * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
     * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
     * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     */
    /*
     *  ======== TMS320F28377S.cmd ========
     *  Define the memory block start/length for the TMS320F28377S
     */
     
    MEMORY
    {
    PAGE 0 :  /* Program Memory */
    
        D01SARAM   : origin = 0x00B000, length = 0x001000
    
        /* Flash boot address */
        BOOT_VECTOR : origin = 0x080000, length = 0x000002
    
        /* application starting address */
        BEGIN   : origin = 0x084000, length = 0x000002
    
        /* Flash sectors */
        FLASHC  : origin = 0x084002, length = 0x001FFE  /* on-chip Flash */
        FLASHD  : origin = 0x086000, length = 0x002000  /* on-chip Flash */
        FLASHE  : origin = 0x088000, length = 0x008000  /* on-chip Flash */
        FLASHF  : origin = 0x090000, length = 0x008000  /* on-chip Flash */
        FLASHG  : origin = 0x098000, length = 0x007FFD  /* on-chip Flash */
        APP_CRC : origin = 0x09FFFE, length = 0x01      /* on-chip Flash */
        APP_STATUS: origin = 0x09FFFF, length = 0x01      /* on-chip Flash */
    
        RESET   : origin = 0x3FFFC0, length = 0x000002
        
    PAGE 1 : /* Data Memory */
    
        BOOT_RSVD : origin = 0x000002, length = 0x000120 /* Part of M0, BOOT rom
                                                            will use this for
                                                            stack */
    
        M01SARAM : origin = 0x000122, length = 0x0006DE  /* on-chip RAM */
    
        LS05SARAM : origin = 0x008000, length = 0x003000 /* on-chip RAM */
    
    
        /* on-chip Global shared RAMs */
        RAMGS0  : origin = 0x00C000, length = 0x001000
        RAMGS1  : origin = 0x00D000, length = 0x001000
        RAMGS2  : origin = 0x00E000, 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
         /* External RAM CS3 512x16 */
        EXTRAM  : origin = 0x300000, length = 0x080000
    
    }
    
    
    SECTIONS
    {
        /* Allocate program areas: */
        .cinit              : > FLASHC | FLASHD | FLASHE | FLASHF | FLASHG PAGE = 0
        .binit              : > FLASHC | FLASHD | FLASHE | FLASHF | FLASHG PAGE = 0
        .pinit              : > FLASHC | FLASHD | FLASHE | FLASHF | FLASHG PAGE = 0
        .text               : >> FLASHC | FLASHD | FLASHE | FLASHF | FLASHG PAGE = 0
        codestart           : > BEGIN   PAGE = 0
    
        ramfuncs :
        LOAD = FLASHD,
        RUN  = D01SARAM,
        LOAD_START(_RamfuncsLoadStart),
        LOAD_SIZE(_RamfuncsLoadSize),
        LOAD_END(_RamfuncsLoadEnd),
        RUN_START(_RamfuncsRunStart),
        RUN_SIZE(_RamfuncsRunSize),
        RUN_END(_RamfuncsRunEnd),
        PAGE = 0
    /*    {
           -l F021_API_F2837xD_FPU32.lib(.text)
        }
    */
        /* Allocate uninitalized data sections: */
        .stack              : > M01SARAM  | LS05SARAM PAGE = 1
        .ebss               : >> M01SARAM | LS05SARAM  | RAMGS0 | RAMGS1 | RAMGS2 | RAMGS3  | RAMGS4 | RAMGS5 | RAMGS6 | RAMGS7 | EXTRAM PAGE = 1
        .esysmem            : >  M01SARAM | LS05SARAM    PAGE = 1
        .cio                : >  M01SARAM  | RAMGS2   PAGE = 1
    
        /* Initalized sections go in Flash */
        .econst             : > FLASHC | FLASHD | FLASHE | FLASHF | FLASHG PAGE = 0
        .switch             : > FLASHC | FLASHD | FLASHE | FLASHF | FLASHG PAGE = 0
        .args               : > FLASHC | FLASHD | FLASHE | FLASHF | FLASHG PAGE = 0
        .reset              : > RESET,     PAGE = 0, TYPE = DSECT /* not used, */
    
        //  FLASH boot entry point for 28377x at 0x80000.
        //  The 'start.asm' file contains the .entry section which contains
        //  a 'LB 0x84000' to vector the code to the codestart entry point.
        //
        .bootentry: > BOOT_VECTOR PAGE = 0
        .appcrc:    > APP_CRC PAGE = 0
    
    }
    
    

    RFC.txt

  • The map file shows no input sections from the library F021_API_F2837xD_FPU32.lib.  This means your main application code calls none of the functions in that library.  Therefore the ramfuncs output section is empty.  The diagnostic "no matching sections" means no input sections match the input section specification ...

           -l F021_API_F2837xD_FPU32.lib(.text)
    

    Thanks and regards,

    -George

  • George,

    That is useful info however I have code in the file that calls what I presumed are the flash api for the f28377S that were used in example app.

    When I comment that code in, in addition to the no matching section it will not link the app so I cannto get a map file and I get the following unresolved externals

    Description Resource Path Location Type
    #10010 errors encountered during linking; "RFC.out" not built nGen Controller    C/C++ Problem
    <a href="file:/c:/ti/ccsv6/tools/compiler/dmed/HTML/10234.html">#10234-D</a>  unresolved symbols remain nGen Controller    C/C++ Problem
    unresolved symbol Fapi_initializeAPI(volatile, first referenced in FMC_REGISTERS nGen Controller    C/C++ Problem
    unresolved symbol Fapi_setActiveFlashBank(Fapi_FlashBankType), first referenced in ./UnloadApp.obj nGen Controller    C/C++ Problem

    These functions are listed in the flash api include file F021.h and were sued in the example app also

    In addition the functions that call the flash API are also referenced in the application.

    I can set breakpoints in them if I comment out the calls and allow application to link.

    To verify this I instantiated the object in main and ran to code that would call the flash API if it were commented in.

    Maury

  • I'm not certain about how to interpret the error diagnostic.  It is a confusing combination of compiler output and formatting from the Problems view in CCS.  Next time, please copy-n-paste the compiler output from the Console view.  

    That said, I think this means your code calls the functions Fapi_initializeAPI and Fapi_setActiveFlashBank, but no implementation of those functions can be found.  Usually, this means the library which contains these functions is not seen by the linker.  That doesn't make much sense.  But that is the only way I see to interpret it.

    Thanks and regards,

    -George

  • George,
    I agree it is like the linker is just not linking this library into the application and I do not understand what would cause this behavior.
    It is not like it says it cannot find the library or not enough space or something else.
    I was attributing it to the fact that the warning no matching section had something to do with this.
    Would that warning cause linker to not link library?
    Note I was trying to put this in the ramfuncs section and I moved it to (Flash_API) to try and get some more info.
    At this point I am not yet copying the Flash_API from flash to RAM in the code - would that be an issue?

    Here are the messages from console:
    <Linking>
    "../TMS320F28377S_NO_APPL.cmd", line 121: warning #10068-D: no matching section

    undefined first referenced
    symbol in file
    --------- ----------------
    Fapi_initializeAPI(volatile FMC_REGISTERS *, unsigned long) ./UnloadApp.obj
    Fapi_setActiveFlashBank(Fapi_FlashBankType) ./UnloadApp.obj

    error #10234-D: unresolved symbols remain
    error #10010: errors encountered during linking; "RFC.out" not built

    Maury
  • At this point, the only way I see forward is for you to submit the full CCS project.  That is the only way this problem can be diagnosed.  Please see this post for details on how to submit your project.

    Thanks and regards,

    -George

  • George,
    Thanks for your help it steered me in direction of the solution understanding what the warnings mean.
    As it turns out the header for the flash api libraries f021.h does not conatin the C++ construct
    #ifdef __cplusplus
    extern "C" {
    #endif
    So all the functions we invisible and so the library was not called and hence did not link.
    When I added calls to functions they went unresolved due to the C++ name mangling
    Maury
    I'll close this issue