• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 34 subscribers
  • Views 124 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.

SYSCONFIG: Multicore project with shared memory regions cannot be built as both a project and standalone

Nathan Ostrye
Prodigy 220 points
Part Number: SYSCONFIG


Tool/software:

When working with a multicore project for an AM263Px part, the shared memory regions are defined in the Core 0 syscfg. Doing so allows the system project to be built, and Cores 1, 2, and 3 to inherit the shared regions.  However, if the project for Core 1 is opened independently and built, the linker will fail due to missing memory regions. I have attempted to work around this by replicating the shared memory regions on Core 1 in sysconfig. This solution works when the Core 1 is opened independently, but the system project will fail to build due to conflicting memory regions.

So what is the solution to having a shared memory region in sysconfig which can be built both as a system project (all cores) as well as when building a single core's project standalone?

  • 0
    Mastermind 9345 points

    I think it might help if you explain why you need to work in this way. i.e. Why you need to open the .syscfg file using the SYSCONFIG standalone tool instead of within CCS.

  • 0 in reply to Kier
    Prodigy 220 points

    In this instance, we are using a headless build for the software on Core 1_0. This will eventually be the only software our end customers have the ability to write and re-program, so it must be capable of being built independently. For our development purposes, it is also necessary for us to have the syscfg files of the whole project working within a single higher level project to help speed development, debug, and just for ease of use. 

    We currently have work-arounds in place to allow both scenarios to work, but it adds extra steps for us. It seems easier for each syscfg file to have knowledge of the shared memory regions so that syscfg generates the same files whether we are building a core's project independently or from within a multi-core project.

  • 0
    Mastermind 9345 points

    This looks like one for TI. Meanwhile....

    Nathan Ostrye said:
    the linker will fail due to missing memory regions

    Perhaps there's a chance you could suppress the error by demoting the error code to a warning. See example CODECOMPOSER: Linker Fatal Error When Object File Not Present - Code Composer Studio forum - Code Composer StudioTm︎ - TI E2E support forums

  • 0 in reply to Kier
    Prodigy 220 points

    Unfortunately in this case, the error is valid. because the linker file is missing the shared memory regions between the cores, and we are specifically placing things in that memory region for this core, I would fully expect the linker to fail.

    The current workaround is to build a valid linker by building the system project. then copy that generated linker into a static location, exclude the linker.cmd from the syscfg build, and exclude the exclude folder from the build. Its not the worst work around, but its clunky to make changes in the memory mapping at this stage of our development.

  • 0 in reply to Nathan Ostrye
    Mastermind 9345 points

    I guess this would be a feature request to the SYSCONFIG team along the lines of "Standalone SYSCONFIG To Be Multicore Aware".

    Perhaps  could comment?

  • 0 in reply to Kier
    TI__Genius 15670 points

    Hi Kier, Nathan, 

    The standalone, command line sysconfig build tool can accept multiple .syscfg scripts. Probably the easiest way to get what the command line needs to be is to build a multi-core project in CCS and inspec the command in build output window. I believe this might allow you to generate shared memory files from Core0. 

    We are working on a feature that would allow you to create a resource "constraints" file that a system architect would define allocating resources that a particular core can use. This constraints file would be used to limit what can be configured through sysconfig on a particular core. There are still a few items being ironed out and it would require SDK to use/enable this functionality. However, this at a high level sounds like what you are trying to do. 

    Martin