• Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 1196 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

M3 problem with ramfuncs

Gernot Landskron
Prodigy 10 points

Hi, I have the following problem: I have written a program that needs some functions to be in RAM for self-flashing the controller. It was working without any problems until I decided to put this functions, together with some others, in a library, lets call it os.lib, and link it to an application project. Now I have the problem that some of the library are still linked to the "ramfuncs" section, but others are not. A little example:

The files first.c and second.c are part of the "os.lib" now, in the working version they were compiled together with the application part of the project.

first.c

#pragma CODE_SECTION(firstFunction,".ramfuncs");
void firstFunction(void)
{
    // some code
}

second.c

#pragma CODE_SECTION(secondFunction,".ramfuncs");
void secondFunction(void)
{
    // some code
}

Linker command file of the application project where the library is linked to:

MEMORY
{
    ...
    FLASHLOAD (RX)  : origin = 0x00201200, length = 0x3600   /* For storing code in Flash to copy to RAM at runtime */
   ...
}

/* Section allocation in memory */

SECTIONS
{
    .intvecs:   > INTVECS
    .resetisr:  > RESETISR
    .text   :   > FLASH
    .const  :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH

    .vtable :   > C0 | C1 | C2 | C3
    .data   :   > C2 | C3
    .bss    :   > C2 | C3
    .sysmem :   > C0 | C1 | C2 | C3
    .stack  :   > C0 | C1 | C2 | C3

    .dmactrltab  : > C2 | C3
    .heapram     : > SH

     GROUP
     {
         .ramfuncs
         { -l F021_API_CortexM3_LE.lib}
     }    LOAD = FLASHLOAD,
          RUN = C0,
          LOAD_START(ramfuncsLoadStart),
          LOAD_SIZE(ramfuncsLoadSize),
          RUN_START(ramfuncsRunStart),
          PAGE = 0
}

Important detail: I don't want to put the whole "os.lib" into the RAM (like I do with the F021_API.lib), I only want to put some special functions into RAM.

Linker map file from the pplication project:

.ramfuncs
*          0    00201200    000020fc     RUN ADDR = 20000000
...
                  00202fd4    00000084                : first.obj (.ramfuncs:firstFunction)
                  00203058    0000000a                : second.obj (.tramp.secondFunction.1)

.text      0    00204800    0000727e     
                  0020b458    0000002e         os.lib : second.obj (.text:secondFunction)
                  ...
                  0020ba74    0000000a                : first.obj (.tramp.firstFunction.1)

As you can see, the first function is fully put into the .ramfuncs section and 10 bytes of .tramp (whatever this is) is in flash memory, while the second function is NOT put into the .ramfuncs section but in the text section, while in the RAM only is the .tramp part of it. Additionally, I have to say that there are some more functions in first.c, they are also put to the .ramfuncs section, while other functions in second.c are also in the text function, altought they have a similar PRAGMA directive as firstFunction and secondFunction. Using the linker command file to put the whole first.obj and second.obj (or even the whole os.lib) to the .ramfuncs section would be the last option, because this would need way too much RAM.

Do you have any idea what could cause this problem?

  • TI__Mastermind 22025 points

    Gernot,

    This is an interesting problem you present.  I've done similar things with the C28x compiler and not had this issue.  Since this is really a code gen issue, not so much a C2000 device issue, I'm going to move this to their forums to see if they can shed some light on this behavior.

    Could you tell us what version of the compiler you're using?

    BR,

  • in reply to Trey German289
    Prodigy 65 points

    Hi Trey,

    at first, the other account was not mine, I was accidently logged int with it on that computer, this account is the right one.

    Secondly, I am using the TI armcc  5.0.7 for the M3. On the C2K core of the concerto (sorry, I havn't seen until now that I forgot to write that I am unsing a concerto device, sorry for that) ramfuncs are working without any problems. Before I had put my code into a library, it also worked without any problem. Is it possible that assigning sections to functions doesn't work proper when you compile it to a library?

    I have a estimated number of about 20-30 functions I want to put in RAM, but only about a third of them does finally really get linked to the .ramfuncs section, all others are in .text and only a .tramp (trmpoline?) is in .ramfuncs. Other sections, like .csmpswd work as they should.

    Edit:

    I have found out, that if I turn off the using of trampolines by the linker ("--trampolines=off" option), the functions are placed in .ramfuncs correctly (but now I get a warning that the functions cannot be reached by a call due a address overflow). So, obviously the linker confuses trampoline and real function in some cases and he places the trampoline in .ramfuncs instead the real function.

    Aditionally, I have tried to compile all files at once (instead linking the library against the application project I addedthe libraries source with a linked foler in CCS) and it works like it should. So I really think that the linker has a problems with functions that should be put to a section when they are contained in a library.

    Regards, Florian

  • TI__Guru**** 253190 points

    From firstFunction the key C source line is ...

    Gernot Landskron said:
    #pragma CODE_SECTION(firstFunction,".ramfuncs");

    And from the map file I can tell it is in an input section named .ramfuncs:firstFunction ...

    Gernot Landskron said:
                      00202fd4    00000084                : first.obj (.ramfuncs:firstFunction)

    You must be building with --gen_func_subsections (or -ms for short).  Otherwise the input section would be named .ramfuncs.  

    I expect secondFunction to be handled the same way.  But it isn't.  The C source line matches the pattern ...

    Gernot Landskron said:
    #pragma CODE_SECTION(secondFunction,".ramfuncs");

    But the line from the map file does not match the pattern  ...

    Gernot Landskron said:
                     0020b458    0000002e         os.lib : second.obj (.text:secondFunction)

    Why is it a subsection of .text, and not .ramfuncs?  I don't know.  We need to explain this.  Are both of these files being built with the exact same compiler options?  What are those options?

    Just to set your expectation ... I'm more puzzled than usual by this one.  It may take a few exchanges between us before we get to the root of the problem.

    One last minor note ... Do not get confused by how "os.lib" appears in one map file line but not the other.  Just for now, trust me when I say it is of no concern.  If you are really curious, I can explain it.  But that would take a bit, and it won't help advance the main issue.

    Thanks and regards,

    -George

  • in reply to George Mock
    Prodigy 65 points

    Yes, i am using the --gen_func_subsections option. But with "--gen_func_subsections=off" (both projects) the map file looks exactly the same. The other options used for the application project are

    -mv7M3 --code_state=16 --abi=eabi -me -g --include_path="..." --gcc --define=ccs --define=_DEBUG --define=_FLASH --define=COREM3 --diag_warning=225 --display_error_number --gen_func_subsections=on -k --ual

    The arguments used for building the library are

    -mv7M3 --code_state=16 --abi=eabi -me -g --include_path="C:/ti/ccsv5/tools/compiler/arm_5.0.7/include" --gcc --define=ccs --define=COREM3 --diag_warning=225 --display_error_number --diag_wrap=off --gen_func_subsections=on --ual

    Linker arguments for the application:

    -mv7M3 --code_state=16 --abi=eabi -me -g --gcc --define=ccs --define=_DEBUG --define=_FLASH --define=COREM3 --diag_warning=225 --display_error_number --gen_func_subsections=on -k --ual -z --stack_size=1024 -m"m3.map" --heap_size=0 -i"C:/ti/ccsv5/tools/compiler/arm_5.0.7/lib" -i"C:/ti/ccsv5/tools/compiler/arm_5.0.7/include" --reread_libs --warn_sections --display_error_number --rom_model

    George Mock said:
    Why is it a subsection of .text, and not .ramfuncs?  I don't know.

    And why are the function trampulines are placed in RAM, where they can't be reached by an normal function call at all?

    Regards

  • in reply to Florian Griessler
    TI__Guru**** 253190 points

    Well, there is a lot going on here.  I think we need to grab on to one piece of it and try and explain it.

    I think the simplest question at this point is: Why is the code for secondFunction from second.obj in the .text section, when it is expected in the .ramfuncs section?  Please send me the source for second.c, probably preprocessed as describe here.  I'll use the build options you show above, and I see you are using the ARM compiler version 5.0.7.

    Thanks and regards,

    -George