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.

How to change placement of sysbios text and data in memory map

Other Parts Discussed in Thread: SYSBIOS

CCS 6.1.2
Compiler 7.4.16
DSP C6748

Where do you control the placement of the SYSBIOS pieces in the memory map?  Right now everything is going to DDR, but I'd like to move some to internal memory (L3_CBA_RAM).

For example, my SYSBIOS project has the following .text sections I'd like to control:  sysbios.ae674, stk.ae674 (NDK), and rts6740_elf.lib.  The platform file doesn't give me control of those, and I can't find them in the XGCONF tool.  Attached is my MAP file for the project I'm working on.

Things were much easier in the DSPBIOS days, everything was under one roof.  For whatever reason SYSBIOS has split things up.

- Dean

8015.AgentPortCardV2.txt

  • Dean,
    this link explains two options that you have - rtsc.eclipse.org/.../Memory_Management. The first one is to create another linker command file and specify section allocations in that file. The second option, described in the section right after the linker one is to use Program.sectMap.
    In both cases you'll have to know the syntax for referencing sections from libraries. It is explained in www.ti.com/.../spru186w.pdf, Section 7.5.4.5 Specifying Library or Archive Members as Input to Output Sections.
  • I was able to make some progress using my own linker command file.  The stuff below worked, and the RTS6740Text appeared in my .map file.

    SECTIONS
    {
       RTS6740Text  {-l=rts6740_elf.lib(.text)} > DDR
    }

    However if I try the following, I get #10008-D cannot find file.  Both stk.ae674 and sysbios.ae674 are in my .map file.

    SECTIONS
    {
       SYSBIOSText  {-l=sysbios.ae674(.text)} > DDR

       NDKText  {-l=stk.ae674(.text)} > DDR
    }

    - Dean

  • Dean,
    I think the first library is on the library search path so the linker can find it. For other two, you are probably missing some additional path components. You'll need to add directories where those libraries are to the search path. Go to Project Properties->CCS Build->Linker->File Search Path and add them there.
  • Something doesn't make sense. If I take out my custom linker command file, everything links fine and builds a .out file. No errors, no problems. It's only when I try to reference these libraries in the customer linker file, that I get the errors. So the linker has all the path info it needs to build and link, but can't find the files to do the custom placement in memory? This shouldn't be so hard.

    - Dean
  • I am not a linker expert, but as far as I know the linker searches for the libraries you specified, sysbios and stk, along the search path and in the current directory. Since these libraries can't be found in either of these places, the link step fails. If you check the file linker.cmd you'll find two libraries with the base filenames sysbios.ae674 and stk.ae674, but they are supplied with their absolute paths and that's how the linker can find them. However, the linker doesn't do the type of matching where it would recognize that the base filenames of the libraries with absolute paths are the same as the base filenames of the libraries specified in your file, and then just assume these are the same libraries. You still have to add their directories to the search path or use absolute paths.

  • The link doesn't fail, it works just fine. I'm able to build .out files and emulate. It only fails when add the custom linker command file. If the linker found the libraries before, why should I be required to do extra work in my project? By the way, I have run this experiment on a CCSV5.5 setup and everything works as expected. CCSV5.5 is able to find sysbios.ae674 and stk.ae674 in my custom linker command file without any other project modifications.

    If you aren't a linker expert, can you pass this thread onto someone within TI that is?

    Thanks, Dean
  • I'm not sure where the problem lies.  Without a test case to work against, I can only guess at solutions.

    Make sure the linker sees the --include_path (or the equivalent -I) options before it sees the linker command file that relies on them.

    Try putting the -l=sysbios.ae674 in quotes.  And try removing the = character.  These steps should not be necessary.  But I know the linker has had trouble parsing library names in the SECTIONS directive before.  There might be some lingering problem or another.  

    Hope this helps ...

    -George

  • George,

    Thanks for jumping in to help. I tried all your combinations of quotes and removing the = character. No luck. There is nothing special about my SYSBIOS project. Take any of yours, or create a small hello world project. You should be able to reproduce my problem. Again, this works on other machine running CCSV5.5. I've recently upgraded my machine to CCSV6.1, and now my linker command file is broken. Sounds like a tool issue you guys should be able to reproduce and fix. Let me know what you find.

    Thanks, Dean
  • Can you please export a project with the problem and attached it? Please do a clean before exporting and delete the "debug"/"release" directories to keep the zips small.

    Todd
  • Never tried to export a project before, so let me know if this doesn't work.

    - Dean

    5460.TempProjectForTI.zip

  • Dean,
    I replicated your problem and I verified that the solution I proposed before, where you add the path to sysbios.ae674 to Project Properties->CCS Build->C6000 Linker->File Search Path, works and the link step finishes without errors.
    What also works is to replace the relative path
    SYSBIOSText {-l=sysbios.ae674(.text)} > L3_CBA_RAM
    with an absolute path
    SYSBIOSText {-l=C:\Users\a0868339\workspace_v6_1_1\TempProjectForTI\src\sysbios\sysbios.ae674(.text)} > L3_CBA_RAM

    The third solution is to use Project Properties->CCS Build->Link Order functionality. You can change the order of the linker command files, and insert the generated linker command file before your custom file. It seems that the linker recognizes a relative reference to the library if it already encountered that library through an absolute path. That's news to me, and I am not sure how exactly that works, but it does.
  • Sasha,

    Thanks for your (3) solutions. The third solution works best for me, and I verified it fixed my problem. TI may want to invest a little time coming up with a better tool to control where sections go. The custom linker command file, with the weird text parsing (use double quote or not, use = or not, etc) seems very "DOS command prompt". At any rate, thanks again.

    - Dean