• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 556 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.

SYS/BIOS V6.33 issue: customized platform + supplemental linker command file could not work

lz li
Prodigy 180 points
Other Parts Discussed in Thread: TMS320F28335, SYSBIOS

Hi,

In SYS/BIOS V6.33, we could apply customized platform to configure the target/board, which would generate default linker command file linker.cmd automatically by SYS/BIOS.

Also extra supplemental linker command file could be added for some specific memory and section definition.

So I did following test in one project based on TI SYS/BIOS example:

Configuration 1: Customized platform only (exclude the TMS320F28335.cmd from compile);

Configuration 2: default platform + supplemental linker command file (default TMS320F28335.cmd).

Both of the two configurations could be compiled successfully.Then I tried to exclude TMS320F28335.cmd from compile in configuration 2, but it failed to compile due to the sections such as .text,.ebss are failed to map.

So what is the difference between customized platform and default platform? when apply the platform only, why customized platform could work but the default one could not?

Then I deep into the code and found the linker.com of customized platform would generate the memory segment and section definition, but the linker.cmd from default platform has no such information, but instead only contain following info:

SECTIONS
{
    xdc.meta: type = COPY
}

So what will make the difference between the two linker.cmd? And what configuration should I pay attention to manipulate it?

Thanks very much by advance!

Best regards!

  • 0
    TI__Mastermind 37985 points

    What you described in your post is exactly how those two platforms are designed to work.
    The default platform gives you a complete control of the linker command file. The supplemental command file is a part of the project and you can customize it, and use some advanced linker command file syntax that is not available for the generated linker command files (GROUPS, UNIONS, etc.). If you need that then the default platform is a better choice.
    If you only want to reorganize your memory map, you may want to use your own customized platforms. You could also reorganize the memory map in the supplemental linker command file, but if you are using the same platform in multiple projects, it's easier to create a customized platform and point to it rather than copy the supplemental linker command file from project to project.
    So depending on your use cases, you would use one or the other, but for many simpler projects in terms of complexity of linker command files, either will work just fine.

  • 0 in reply to Sasha Slijepcevic
    Prodigy 180 points

    Hi Sasha,

    Thanks very much for your kind and fast response!

    Yes, I know the principle, but currently we are evaluating the OS for our coming project and sysbios is one of the most preferred option.

    In fact, my confusing point is that, what will affect the generated linker command file? Sometimes the generated linker command file would include the memory segment and section definition, but sometimes not, so by what configuration we can control it?

    Hope hear from you soon!

    Best regards!

  • 0 in reply to lz li
    Prodigy 180 points

    Hi Sasha,

    One more question about platform and supplemental linker command file.

    When one project is created based on the TI example, it will automatically select one default platform as well as one default supplemental linker command file (TMS320F28335.cmd). Both of them would define the memory segment and section (In platform only point out the code, data and stack place, no detail section definition).

    From my point of view, they have been double defined, so what is the relationship between the two definitions? It seems that the supplemental linker command file would overrides that from default platform?

    Best regards!

  • 0 in reply to lz li
    TI__Mastermind 37985 points

    The content of the generated linker command file is controlled by the platform. If you want the memory definition and standard section allocations to be specified in the generated file, you choose the platform that does that (in this case the customized platform), and you remove the default supplemental linker command file from your project. If you want to be able to edit the linker command file manually, you can choose the default platform and keep the supplemental linker command file.
    Most platforms generate the memory definition and standard sections allocations, but there are a few generic platforms that don't do that, and 'ti.platforms.tms320x28' is one of them.

    There are more details to it, for example you can exclude some sections from the generated linker command file even though you selected a platform that generates the memory definition and section allocations. You can do it using Program.sectionsExclude and Program.sectionsTemplate. But, these are mostly used for devices when a generic platform that doesn't generate the memory definition and sections is not available.

    As for your question about the examples, the case you are describing could be a bug. What is supposed to happen when you choose an example is that a default generic platform is used and the supplemental linker command file is added. Because the default platform does not define the memory segments and standard sections allocations, nothing should be defined twice. I verified in CCS 5.1 that the examples are working just as I described. Are you seeing something different?