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.

Copying rts2800_fpu32.lib from Flash to RAM on TMS320F28335. No matching section.

Hi,


I'm trying to copy sections of my code from Flash to RAM for better performance. I can do this with my own functions using the following section of the linker:

   RAML0       : origin = 0x008000, length = 0x001000     /* on-chip RAM block L0 */

   ramfuncs            : LOAD = FLASHD,
                         RUN = RAML0,
                         LOAD_START(_RamfuncsLoadStart),
                         LOAD_END(_RamfuncsLoadEnd),
                         RUN_START(_RamfuncsRunStart),
                         PAGE = 0

Then copying this using the MemCopy function, and a #pragma CODE_SECTION directive. This works fine.


However, I have been trying to copy functions from the rts2800_fpu32.lib into RAM to make this run using the following in the linker. This again requires the MemCopy function but as I understand does not need a #pragma. As I understand this should copy the full library into RAM from flash.

   RAML1       : origin = 0x009000, length = 0x003000      /* on-chip RAM block L1 */

   maths               : LOAD = FLASHB
                         RUN = RAML1,
                         LOAD_START(_MathLoadStart),
                         LOAD_END(_MathLoadEnd),
                         RUN_START(_MathRunStart),
                         PAGE = 0,
                         {
                             -l rts2800_fpu32.lib (.text)
                         }

However, I get a warning on compilation and the copy fails:

#10068-D no matching section

I have been looking around the forums and came across this post which seems to suggest I am doing things right, however one of the entries suggests there is a known bug that changing the project options from automatic to include the specific library being included. However this does not solve the issue. I think the fix mentioned in the post relates to CCSv4, I am using CCSv5. Are there any other known issues surrounding this or is there something else I am missing?


Thanks,

Adam

  • Adam,

    Are you sure you've called at least one function that is in the rts2800_fpu32.lib?  The warning you are getting suggests to me that there is no matching section because the section was never created (since you aren't calling any functions from the library).

    Check the .map file to see if there are any functions that use the .text section in the rts2800_fpu32.lib.

    Regards,

    David

  • Hi David,

    I am calling several functions that are in the .text section (small excerpt below):

    .text      0    00330000    00000f7c     
    ...
                      00330c4e    00000088     rts2800_fpu32.lib : fs_div.obj (.text)
                      00330cd6    0000006a                       : exp.obj (.text)
                      00330d40    00000061                       : cos.obj (.text)
                      00330da1    00000057                       : sin.obj (.text)
                      00330df8    00000046                       : boot.obj (.text)
    ...
                      00330e81    00000035     rts2800_fpu32.lib : ldexp.obj (.text)
    ...
                      00330ee4    00000023     rts2800_fpu32.lib : sqrt.obj (.text)
                      00330f07    00000019                       : args_main.obj (.text)
                      00330f20    00000019                       : exit.obj (.text)
                      00330f39    00000016                       : frexp.obj (.text)

    There are also functions in the (.cinit) and (.econst) sections but if I add these as -l search path they give the same warning.

    Thanks and regards,

    Adam

  • Adam,

    I did some testing for you, and I know where your mistake is.  Let me first point out that you cannot copy the entire rts library to RAM.  The boot.obj (_c_int00 function) will execute before you get to main() and are able to do the copying.  Remember that the user code must do the copying.  The compiler does NOT generate the copy code.  The section boot.obj must remain in flash.

    Now, to the mistake.  The syntax in the linker command is tricky!  You did a great job getting as far as you did.  Here is what you need to put in your linker .cmd file:

    rts2800_fpu32_FLASH : > FLASH_ABCDEFGH,       PAGE = 0
                            {
                              rts2800_fpu32.lib <boot.obj> (.text)
                            }

    rts2800_fpu32_RAM   :   LOAD = FLASH_ABCDEFGH, PAGE = 0
                            RUN = L0123SARAM,      PAGE = 0
                            LOAD_START(_rts2800_fpu32_RAM_loadstart),
                            LOAD_SIZE(_rts2800_fpu32_RAM_loadsize),
                            RUN_START(_rts2800_fpu32_RAM_runstart)
                            {
                              rts2800_fpu32.lib <*> (.text)
                            }

    The new section names, rts2800_fpu32_FLASH and rts2800_fpu32_RAM are just my choices.  You can use whatever you want (e.g., you had been using 'maths' instead of rts2800_fpu32_RAM).  Similarly, the memory names are just my examples.

    The section rts2800_fpu32_FLASH contains only the boot.obj module from the library.  This needs to stay in flash.  The section rts2800_fpu32_RAM contains EVERYTHING else from the library since I used the <*> to designate the .obj modules in the new section.  You copy this section from flash to RAM using the labels being generated.

    Note that you could list additional object modules that you want to stay in flash if you want.  For example, suppose I was using the pow function (power), and I wanted to keep it in flash as well (because I was carefully managing my RAM consumption).  You would do this:

    rts2800_fpu32_FLASH : > FLASH_ABCDEFGH,       PAGE = 0
                            {
                              rts2800_fpu32.lib <boot.obj> (.text)
                              rts2800_fpu32.lib <pow.obj> (.text)
                            }

    If most of your functions were staying in flash, you wouldn't need the rts2800_fpu32_FLASH section at all (the library would just link with the regular .text section) and instead you would list the individual object modules you wanted to move to RAM for the rts2800_fpu32_RAM section.  It just depends on which is easiest.

    This should work for you.  Good luck.

    Regards,

    David

  • Hi David,


    Many thanks for your help. I altered my linker and now have the following:

       rts2800_fpu32_FLASH : > FLASHB,       PAGE = 0
                             {
                                 -l rts2800_fpu32.lib <boot.obj> (.text)
                             }
       rts2800_fpu32_RAM     : LOAD = FLASHB
                             RUN = RAML1,
                             LOAD_START(_MathLoadStart),
                             LOAD_END(_MathLoadEnd),
                             RUN_START(_MathRunStart),
                             PAGE = 0,
                             {
                                 -l rts2800_fpu32.lib <*> (.text)
                             }


    I also tried without the -l and with <sin.obj> as the only function to move to RAM but I still get the warning on the two .lib lines. Every line I put on with the .lib comes up with this warning.


    Thanks,

    Adam

  • Adam,

    I'm not sure what is going on with your project.  What I showed is correct.  I've tested it.

    I've attached my simple test project.  It is a CCSv5.5 project.  Perhaps you can spot the difference between my project and what you are doing.

    Regards,

    David

    F28335_example_nonBIOS_flash_TEST.zip
  • Hi David,


    Many thanks for that. I had a look at you project (though I had to import the files into a new project of my own, I'm on CCS5.3 and v6.1 of the compiler) and initially had the same type of warnings, but changing the Runtime Support Library to rts2800_fpu32.lib cured this.

    So I went back to my project and checked I had done this (which I had), however looking further in C2000 Linker > File Search Path I had:

    "C:\ti\ccsv5\tools\compiler\c2000_6.1.0\lib\libc.a"

    "rts2800_fpu32.lib"

    in that order. Switching the order and rebuilding worked and got rid of the warnings, and the .map file looks correct too. This is with the linker as described in my post above.

    However, when loading and running in debug the program never makes it to main(). I haven't quite worked out what's going on here yet. I will investigate further and report back.


    Again, many thanks for your help in this.


    Adam

  • Adam,

    Adam Ardron said:

    So I went back to my project and checked I had done this (which I had), however looking further in C2000 Linker > File Search Path I had:

    "C:\ti\ccsv5\tools\compiler\c2000_6.1.0\lib\libc.a"

    "rts2800_fpu32.lib"

    in that order. Switching the order and rebuilding worked and got rid of the warnings, and the .map file looks correct too. This is with the linker as described in my post above.

    I don't follow you here.  You are showing a file search path (C:\ti\ccsv5\tools\compiler\c2000_6.1.0\lib\libc.a) and a library file (rts2800_fpu32.lib).  How do you switch the order of these?  They are not the same type of thing.

    The link search path window should look like this:

    And when using libc.a (the automatic library inclusion based on your project options), you specify 'automatic' as the Runtime support library:

    libc.a and rts2800_fpu32.lib do not go together.  libc.a says you want CCS to determine which RTS library it should pull in based on the project settings (e.g., if floating point support is checked, then the fpu32 lib will get pulled in, and so on).

    - David

  • Hi David,


    If I do what you say and rebuild I get the warnings back.

    I'll put some screen shots together and post them.

    Thanks,


    Adam

  • Hi David,

    Screen shots below. Order is changed using the buttons circled in red. I probably don't need the libc.a line anymore but haven't tried without it. Another post will follow:

    Edit - I can't see my screen shots  so will describe:


    where you see "libc.a" in the first I have two lines:

    "rts2800_fpu32.lib"

    "C:\ti\ccsv5\tools\compiler\c2000_6.1.0\lib\libc.a"

    in that order. You can switch the order using the up down arrow to the top left of the box (greyed in you screenshot).


    In you second I see "rts2800_fpu32.lib" (no quotes) instead of <automatic>.

    If I do this I build with no warnings.


    Thanks,


    Adam

  • Hi David,

    Putting the build issues to one side as I said I managed to build without warnings if I altered the properties. However when I ran in debug the program never got to main(). I stepped through the disassembly of my program with and without the attempt to write the .lib to RAM.

    The difference I noticed was the args_main was running from RAM in the second example and this seemed to be preventing from getting to main so I added a line to the linker:

       rts2800_fpu32_FLASH :  > FLASHB,       PAGE = 0
                              {
                                -l rts2800_fpu32.lib <boot.obj> (.text)
                                -l rts2800_fpu32.lib <args_main.obj> (.text) // Added this line
                              }

    Now when I flash the line runs to main but I keep getting a watchdog reset.
     The upshot is any library function I run in RAM seems to fail to return to flash i.e. if I run <sin.obj> in RAM the code runs fine until I call this function, at which point it seems to get stuck in the function and fails to jump back to where it should go next, that is the next line of c code does not get hit.

    I am obviously doing something wrong somewhere but at least I seem to be getting closer. Will keep experimenting.

    Thanks,

    Adam

  • Adam,

    Adam Ardron said:

    The upshot is any library function I run in RAM seems to fail to return to flash i.e. if I run <sin.obj> in RAM the code runs fine until I call this function, at which point it seems to get stuck in the function and fails to jump back to where it should go next, that is the next line of c code does not get hit.

    Are you performing the copy from flash to RAM in your code?  The compiler will not do this for you.  You have to do it yourself (e.g., using memcopy() function, or just write your own copy routine).

    If you are doing the copy already, do you see your functions in the RAM in CCS after the copy is peformed?

    If the functions are in RAM, what happens when you step the function call to the routine (e.g., sin).  You should be able to debug this and find out what is going on with the program counter (PC).

    - David

  • Hi David,

    I found the problem. My memcopy() function is set up for LOAD_END and not LOAD_SIZE so the wrong thing was getting copied. When I changed that it worked fine.

    Many thanks for you help I think this is sorted now.

    Regards,


    Adam