How to Safely Share and Access L3 Memory Area Between Cores on ADSP-SC594

Hi,

Thank you for your inquiry. 

Please find the attached project, which demonstrates how both ARM and SHARC cores can access shared L3 memory for read and write operations.

By default, the L3 memory region is read-only for the SHARC core. Therefore, the ARM core's MMU must be configured accordingly.

The MMU configuration is done based on the Abstract Page Table (APT) defined by symbol _adi_mmu_absPageTable. You can copy the default version of the APT and modify SHARC memory region used for the heap is being accessible by the ARM.

This file can be copied from the below path:

<installation path>CrossCore Embedded Studio x.x.x\ARM\arm-none-eabi\arm-none-eabi\lib\src\cortex-a5\crt\apt-sc594.c

For example replace:
{ 0x80000000u, 0x9FFFFFFFu, SHARC_L3},

With

{ 0x80000000u, 0x9FFFFFFFu, ADI_MMU_RW_UNCACHED},

Please find attached basic project for SC594 which shows that ARM and SHARC can both read and write shared L3 memory. This follows the above 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 in the ARM project is modified at line 116

- The cache is turned off for the shared L3 memory on the SHARC core, using the adi_cache_set_range API

- The example, when run, should print that the value at the L3 address is 2 on the SHARC0 core and value 3 on the SHARC1, then subsequently 3 on the ARM core. To see this, when creating your Debug Configuration, make sure that you remove the Automatic Breakpoint at "main" on Core 1 and Core2 (SHARC0 and SHARC1), so that the SHARC cores runs without stopping when enabled from the ARM.

Also, we recommend to refer the below links, which might be helpful to you.
https://ez.analog.com/dsp/software-and-development-tools/cces/f/q-a/111377/structure-in-memory-accessible-by-all-three-cores
https://ez.analog.com/dsp/sharc-processors/adsp-sc5xxadsp-215xx/f/q-a/63893/multi-core-shared-memory

Hope this helps.

Regards,
Santha kumari.V

SC594_L3_SharedMemory.zip

Hi Santha kumari.V,

Thank you very much for your kind support regarding our previous inquiry.
We appreciate your continued assistance this time as well.
Also, thank you for your prompt response and for providing the sample project.

However, unfortunately, the response and sample project did not meet our expectations.
The provided solution simply sets the shared L3 memory region as non-cacheable, and each core reads and writes to it accordingly.
(Of course, we understand that read/write conflicts are avoided by introducing timing differences (delays).
However, since other cores cannot know exactly when and where the L3 memory region is being accessed, this approach is impractical in reality.)

What we would like to understand is how to implement mutual exclusion in the following cases:

• How to exclude our core's read/write operations when other cores' is writing to the L3 memory region.
• How to exclude our core's write operations when other cores' is reading the L3 memory region (reads are allowed).
• How to exclude other cores' read/write operations when our core's is writing to the L3 memory region.
• How to exclude other cores' write operations when our core's is reading the L3 memory region (reads are allowed).

In other words, we are referring to the commonly known "readers-writer lock" mechanism.

For SHARC cores, we understand that the following APIs are available:

• load_exclusive_8()
• load_exclusive_16()
• load_exclusive_32()
• load_exclusive_64()
• store_exclusive_8()
• store_exclusive_16()
• store_exclusive_32()
• store_exclusive_64()

Is it possible to implement a readers-writer lock using these APIs?

Also, since these APIs are apparently not available on ARM cores, are there alternative APIs on ARM cores that can be used instead?
If it is not possible to implement readers-writer locks using these APIs, could you please advise us on other methods or best practices?

Thank you very much for your kind support.

Best regards,
MrKK

Readers–writer lock:
en.wikipedia.org/.../Readers–writer_lock

Hello Santha Kumari.V,

Thank you for your prompt reply.

As you said, overriding the adi_mmu_Init() function implemented the desired behavior. Thank you very much.

However, we still intend to make various adjustments, such as memory layout and attributes, by editing 'apt_Core0.c' and 'app_Core0.ld' going forward.
Can this issue be avoided continuously while meeting the above requirements using a workaround like the one implemented this time (i.e., simply disabling the MMU)?
Furthermore, we still do not fully understand why this particular workaround enables the expected behavior.

We apologize for the trouble, but could you please explain the mechanism behind why this approach has led to the expected behavior?
Additionally, please advise whether this approach will allow us to continue accommodating various requests for adjustments to memory allocation, attributes, and other aspects in the future.
If this approach proves difficult to continue meeting our requirements, please advise us on an alternative approach.

Best regards,
MrKK

P.S.
We still do not fully understand the mechanism behind why the adi_mmu_Init() function, which is not marked as 'weak', can be implemented in an override.
If it's not too much trouble, we would be very grateful if you could also explain this mechanism to us.

Hi Santha Kumari.V,

We hope you are doing well.
Could you please share a status update when you have a moment?

Based on our observation that the system does not function correctly when the MMU is enabled but works as expected when it is disabled, we have two concerns (and we may be mistaken):

• The virtual address may not be mapped to the correct physical address.
• Data may be remaining in the cache and not reaching the physical address.

We would appreciate your thoughts.

If these concerns are valid, would adding an entry for the correct physical address with a non‑cacheable attribute in the '_adi_mmu_absPageTable' array help the system work properly even with the MMU enabled?
We would appreciate your advice.
Thank you for your continued support.

Best regards,
MrKK

Hello MrKK,

Apologies for the delay in response.

We checked your queries with our Internal team and they have given the below details.

apt_Core0.c and app_Core0.ld source file and the associated linker scripts together determine key system behaviors, including cache configuration and memory layout. Adjustments to cache settings and other low-level parameters should be made based on insights from both files.

You can disable the cache configuration per section listed in the MMU configuration in apt_core.c

For more details regarding apt.c file, please refer the below CCES help path:
CrossCore® Embedded Studio 3.x.x > ARM® Development Tools Documentation > Cortex-A > Analog Devices ARM Toolchain Manual > Analog Devices Specific Linker Support > MMU Configuration

Hope this helps.

Best Regards,
Santhakumari.V

Hi Santha Kumari.V,

Thank you for your reply and for sharing the CCES documentation reference.
While the guidance is helpful, it did not resolve our issue nor address the specific questions we raised.
To move forward, could you please clarify the points below?
If possible, a direct response to each item would be greatly appreciated.

1. Workaround by overriding 'adi_mmu_Init'
   • Overriding 'adi_mmu_Init' function to effectively disable the MMU has produced the expected behavior on our side.
   • Could you advise whether this approach is free of side effects, including but not limited to performance impacts from cache being disabled, issues when running FreeRTOS, effects on peripherals such as UART/I2C/SPI, DMA or interrupts, and any security constraints?
   • If any such side effects could occur, we would prefer not to adopt this method as a long-term solution.
2. Hypotheses for the root cause
   
   • Since the issue occurs only when the MMU is enabled, we would like to confirm whether either of the following (possibly both) could explain the behavior:
     1. a virtual‑to‑physical mapping mismatch, or
     2. a cache coherency issue (data not being written back to physical memory).
   • If these hypotheses are valid, can we resolve the issue while keeping the MMU enabled by correctly updating the relevant entries in '_adi_mmu_absPageTable' (e.g., non‑cacheable attributes for the target address range)?
   • If neither hypothesis is valid, please suggest alternative root causes to investigate and a recommended approach.
3. Recommended fix
   • If the workaround in [1.] has side effects that make continued use difficult, please advise the recommended approach assuming the MMU remains enabled.
   • If [2.] is valid, could you provide an example of recommended settings for '_adi_mmu_absPageTable' (address range and attribute values)?
   • If [2.] is not valid, please suggest an alternative approach.
4. Why overriding a 'non‑weak' function worked
   • Our understanding is that 'adi_mmu_Init' function is not marked as 'weak', yet our implementation was used.
   • Could you explain the mechanism that allowed this override (e.g., linker order, library symbol resolution, project settings, or other factors)?

Thank you for your continued support.

Best regards,
MrKK

Hello MrKK,

Our sincere apologies for the delay in response.

Earlier we suggested to bypass MMU configuration by calling adi_mmu_Init() function. When we checked with our Internal Development team, they said that for testing purpose only this option needs to be suggested. Sorry for the confusion caused here. When we set 1MB DDR in APT file as ADI_MMU_RW_STRONGLY_ORDERED, ARM is not overwriting the content written by the Sharc Core.

{ 0xBFF00000u, 0xBFFFFFFFu, ADI_MMU_RW_STRONGLY_ORDERED}, /* 1MB DDR-A */

Also please note that 4KB ICC region which is used by MCAPI for Intercore Communication also configured with ADI_MMU_RW_STRONGLY_ORDERED memory attribute.

Could you please try this option and let us know how you are getting on.

Best Regards,
Santhakumari.V

Dear Santhakumari.V,

Thank you very much for coordinating with your development team.

In our environment as well, after modifying the APT file as shown below, we confirmed that the ARM core no longer overwrites content written by the SHARC core. We sincerely appreciate your support.
Before:
{ 0xBFF00000u, 0xBFFFFFFFu, ADI_MMU_RW_UNCACHED }, /* 1MB DDR-A */
After:
{ 0xBFF00000u, 0xBFFFFFFFu, ADI_MMU_RW_STRONGLY_ORDERED }, /* 1MB DDR-A */

Additionally, changing from "ADI_MMU_RW_UNCACHED" to "ADI_MMU_RW_STRONGLY_ORDERED" has resolved the issue. Could you please explain the difference between these two settings for our future reference?

Furthermore, after switching to "ADI_MMU_RW_STRONGLY_ORDERED," is the cache enabled or disabled? When we view memory directly via the "Memory Browser", it appears that the cache is disabled. However, if the cache is actually enabled, we would be grateful if you could also advise us on how to disable it.

We appreciate your continued support and look forward to your guidance.

Best regards,
MrKK

Dear Santhakumari.V,

Thank you very much for your support and the guidance you provided.

We have identified the cause and resolved the issue on our side. We confirmed from ARM documentation that UNCACHED and STRONGLY_ORDERED are ARM‑specific memory types, and that STRONGLY_ORDERED is non‑cacheable with strict ordering. The following references were helpful:

• ARM Architecture Reference Manual ARMv7‑A and ARMv7‑R (DDI 0406), Section A3.5 “Memory types and attributes and the memory order model”
  • developer.arm.com/.../latest
• “Strongly‑ordered memory” (DDI 0403)
  • developer.arm.com/.../Strongly-ordered-memory

In light of this, our recent questions were not appropriate for Analog Devices support. We apologize for any confusion. Please kindly disregard our previous queries related to this topic.

We appreciate your assistance and look forward to working with you in the future.

Best regards,
MrKK

Hello MrKK,

Happy to know that the issue got resolved. Thank you so much your patience and your kind words!!!

Best Regards,
Santhakumari.V

Dear Santhakumari.V,

For your reference, we have attached the test code we used for final verification below.
0160.L3Mem_Exclu_Access_Example.zip

Additionally, we report that the warning “Warning li2131” has been resolved by using "#pragma section (".l3_shared_memory", NO_INIT)" instead of "__attribute__((section(".l3_shared_memory")))".
Furthermore, the unresolved issue of “Why can non-weak functions be overridden?” remains pending. However, since this is not directly related to the matter at hand, we will refrain from further discussion on this point.

Based on the above, we would like to close this thread.

We sincerely appreciate your tremendous support thus far.
Should any further assistance be required, we kindly request your continued cooperation.

Best regards,
MrKK

Hello MrKK,

Thank you for sharing the updated code to us.

>>> Should any further assistance be required, we kindly request your continued cooperation.
Sure. We’ll always be here to support you. Thanks so much!

We will close this ticket.

Best Regards,
Santhakumari.V

Hello MrKK,

Thank you for sharing the updated code to us.

>>> Should any further assistance be required, we kindly request your continued cooperation.
Sure. We’ll always be here to support you. Thanks so much!

We will close this ticket.

Best Regards,
Santhakumari.V