Structure in memory accessible by all three cores

Ref: SC584

How can I create a structure in memory that is directly accessible by all three cores.  I do not want to use MCAPI.

  • 0
    •  Analog Employees 
    on May 15, 2019 12:07 PM over 1 year ago


    Please refer the 'SHARED_MEMORY{}' section from page 119-122 in the below CCES Linker and Utilities Manual:

    Santha kumari.K

  • 0
    •  Analog Employees 
    on May 28, 2019 10:02 PM over 1 year ago in reply to santha.vijay

    The recommended way of sharing data between the 3 cores is to use MCAPI - it is officially supported in CCES and we supply documentation and examples to help you get started. Although it is possible to use other methods such as the SHARED_MEMORY method that Santha mentioned, or the SHARC linker's RESOLVE command, these methods are not supported by the ARM tools, and it is easy to make an error that can be difficult to identify later. Could you explain why you are keen to avoid using MCAPI? It would be helpful for us to understand this.

    If you are determined to avoid MCAPI, then using the RESOLVE() command in your LDF is probably simpler than using SHARED_MEMORY{}. This allows you to create your data structure in (for example) the L2 memory for SHARC core 1 and then link against it when building the executable for SHARC core 2. For example, SHARC core 1 might contain C/C++ code like the following

      section ("seg_l2_uncached") volatile int x;

     And this variable can be declared as extern for core 2 (the section qualifier does not need to be repeated here):

      extern volatile int x;

    (Note that 'x' is declared as volatile since it can be changed by multiple programs.)

    In the PROCESSOR command of the LDF for the core 2, the symbol can then be resolved to the definition in the DXE for the core 1:

      RESOLVE(x., "../../SharedMem_Core1/Debug/SharedMem_Core1.dxe")

    As mentioned earlier, the ARM tools do not support RESOLVE, so will need to determine the address of the data structure and then use this address in your code. For example:

    volatile int *x = (int *)0x20083000;

    There are several pitfalls you will need to be aware of:

    • The address of the data structure may change, depending on the rest of the code/data in SHARC core 1 project. If it does, you will need to update the address used in the ARM project. CCES does not provide a way to alert you if the address changes, so it would be up to you to ensure that the projects remain consistent.
    • The RESOLVE command links to a specific executable. If you were to change to using the Release configuration (which builds an executable in a different folder), or if you renamed your project, you would need to remember to update the RESOLVE command.
    • This code uses uncached memory. If cached memory were to be used for sharing, the shared buffer would need to be flushed/invalidated as appropriate when passing data between the cores. See also the flush_data_buffer() function.

    There may be additional pitfalls that are not listed here.

    Attached is an example project that demonstrates this approach - it shows core 0 and core 1 waiting in a loop until core 2 has modified a variable in shared memory before terminating. I hope it demonstrates what is described above, but I really wouldn't recommend it as an approach to sharing memory/data between cores.


  • Hello Kenny,

    Thank you for this detailed response and example.

    I am already using MCAPI to configure a few MDMA channels between the SHARC cores. To be honest, I found the MCAPI configuration effort to be excessive when all I need is to exchange a few scalars (MDMA base addresses). I suppose that if I also needed to use the MCAPI messaging and packet capabilities, perhaps I'd appreciate the protocol a bit more.

    I will now try adding MCAPI to my ARM app to exchange one more scalar. I will reply again when it is running so that we can close this issue.

    Again, thank you for your guidance.

    Best regards,


  • Hello Kenny,

    You can close this issue.

    I've implemented MCAPI on my ARM.  FYI - My image has grown by about 8K to exchange the single 32-bit scalar it needs.   This is a big deal to me because I don't have external memory on my board.  But that is a separate issue that I'll pick away at when I have time.

    Again, thank you for your assistance.

Reply Children