Structure in memory accessible by all three cores

Hello,

Please refer the 'SHARED_MEMORY{}' section from page 119-122 in the below CCES Linker and Utilities Manual:
www.analog.com/.../cces-LinkerUtilities-manual.pdf

Regards,
Santha kumari.K

Hello,

Please refer the 'SHARED_MEMORY{}' section from page 119-122 in the below CCES Linker and Utilities Manual:
www.analog.com/.../cces-LinkerUtilities-manual.pdf

Regards,
Santha kumari.K

Thank you for your reply.

Will this work with the ARM as well as the SHARC cores? Do you have an example project that you can share?

Hello,

Please find attached a very basic project which shows that the ARM and SHARC can both read and write L1 memory. This follows the previous advice (adding a modified abstract page table to the ARM project).

A few notes on the example:
- this is a very naive example. We don't recommend using hard-coded addresses to share data, as is done for clarity here.
- the apt file(apt-sc589.c) in the ARM project is modified at line 134
- the example, when run, should print that the value at the L1 address is 1 on the SHARC core, then subsequently 2 on the ARM core. To see this, when creating your Debug Configuration, make sure you remove the Automatic Breakpoint at "main" on Core 1 (SHARC), so that the SHARC core runs without stopping when enabled from the ARM.

For more information regarding ARM linking, please refer in CCES help:        
CrossCore® Embedded Studio 2.8.0 > ARM® Development Tools Documentation > Cortex-A > Analog Devices ARM Toolchain Manual > Analog Devices Specific Linker Support

Regards,
Santha kumari.K

Shared_memory.zip

Thank you for your response and example.

This example doesn't appear to implement the 'SHARED_MEMORY{}' segment that you originally recommended.

Hello,

We are working on this query. We will get back you soon

Best regards,

Santha kumari.K

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.

Thanks,
Kenny

sc584_shared_mem.zip