I'm running into problems when trying to write to the L1 memory of the second SHARC core from the first SHARC core. I have tried this on both an SC587 and 21584. I am testing with a 21584 for simplicity.
The strange behavior is that after the second SHARC writes to a location in its own L1, the first SHARC core can no longer write to that same location via multiprocessor memory space. The writes have no effect. But this only happens in L1 block 3 SRAM. Blocks 0-2 work fine.
A typical scenario would be like this:
1) SHARC 1 writes to SHARC 2 block 3 using multiprocessor memory space using Slave1 port. This works as expected.
2) SHARC 2 writes to that same location using the direct L1 address.
3) SHARC 1 again writes to SHARC 2 using multiprocessor memory space using Slave1 port. This does not work.
If I use a location in block 2 instead, step 3 works as expected.
I've attached an example project that illustrates the issue. The Core1 .c file lists out detailed debugging instructions to see the failure. Change the value of BASE_ADDR in both core's code to see the working and failing conditions.
Is there some type of caching or memory protection going on here? Cache is turned off in the project for both cores. I haven't made any changes to the system protection registers, so they should be wide open by default.