In our application, the same code runs on core 1 and core 3, but each of the two cores must have their own private copy of data. The data is too big to fit completely in the L2SRAM.
After discussion with TI, we decided not to use the MAD Utilities, but to do something similar but much less general instead (to save some memory and to preserve some legacy behavior from an earlier development, etc.).
This is what we are doing:
The code is shared by the two cores, and a single copy is loaded in MSMC.
The code is linked as if the data in MSMC is at address A
Two copies of data are loaded in MSMC, one copy at address A (for core 1) and one copy at address B (for core 3).
On core 1, nothing special is done. The data is simply at address A.
On core 3, we use MPAX to map data accesses from Corepac address A to MSMC address B.
The MPAX configuration is done on core 3 within _c_int00(), via xdc_runtime_Startup_reset__I(), before BIOS is running and before any MSMC memory accesses are made.
We take care to place the stack in L2SRAM, so that the stack is not relocated by MPAX.
Everything works perfectly on core 1 (with no MPAX mapping).
But when I run this code on core 3, it enters BIOS_start() and never reaches any application code.
The debugger loses contact with core 3 and can’t reconnect.
I’ve looked in the BIOS docs and somewhat in the BIOS code, and I’m not aware of BIOS doing anything that would interfere with our use of MPAX.
As long as BIOS does not overwrite our MPAX config, BIOS on core 3 should be unaware of all this, and should get its own copy of its private data within area B.
Can anyone explain what might be going wrong.
[This is on our C6674 board, but should be much the same as on a C6678 EVM board].
Regards, Jon
