Part Number: 66AK2L06
Tools version: ti-cgt-c6000_8.3.3
Shared memory location (MSMC): 0x0C03B000
I am going to load program into the above mentioned memory section and I wanted to protect it using ti.sysbios.family.c64p.MemoryProtect
- Is it appropriate to use ti.sysbios.family.c64p.MemoryProtect?
- If ti.sysbios.family.c64p.MemoryProtect is appropriate, here is what I have implemented:
In the .cfg file:
...var ExceptionDSP = xdc.useModule('ti.sysbios.family.c64p.Exception');var MemoryProtect = xdc.useModule('ti.sysbios.family.c64p.MemoryProtect');...Program.global.sharedMemoryProgramStart= 0x0C03B000;Program.global.sharedMemoryProgramLen= 4000;......ExceptionDSP.enablePrint = true;Hwi.enableException = true;ExceptionDSP.exceptionHook = '&ExceptionHandler';ExceptionDSP.enableExternalMPC = true;...
In the DSP function .c file:
...volatile UINT32 perm;BOOL mpFlagperm = MemoryProtect_MPPA_UX | MemoryProtect_MPPA_UR | MemoryProtect_MPPA_SX | MemoryProtect_MPPA_SR | MemoryProtect_MPPA_LOCAL; mpFlag=MemoryProtect_setPA((Ptr)(sharedMemoryProgramStart), sharedMemoryProgramLen, (UInt32)perm);
I am getting false when I print out the mpFlag so I don't think I am doing this correctly? I also purposely read and write back the same value to try to trigger the exception but it also did not trigger. Any suggestions?
Please refer to: https://processors.wiki.ti.com/index.php/MemoryProtectionOnKeystoneDevices#:~:text=Memory%20protection%20on%20the%20KeyStone,the%20permissions%20and%20capturing%20violations.
It explains that L1D, L1P and L2 memory protection is controlled by MPPA registers. However, MSMC is controlled by MPAX.
The Sysbios user guide: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_76_01_12/exports/bios_6_76_01_12/docs/cdoc/ti/sysbios/family/c64p/MemoryProtect.html#set.X.M.C.Region
The Bool MemoryProtect_setPA(Ptr addr, SizeT size, UInt32 paMask); calls into MemoryProtect_writePA() which accesses the MPPA register, this will not work MSMC (shared L2).
What you need to use is: Bool MemoryProtect_setXMCRegion(Int8 id, Ptr baseAddr, MemoryProtect_RegionSize size, Ptr rAddr35_12, UInt32 paMask);
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to lding:
MemoryProtect_setXMCRegion() is not available for sysbios 6.75 so I tried to write to the regs directly:
volatile UINT32* ptrMpax;volatile UINT32 *ptrVal;UINT32 value;UINT32 value2;UINT32 tempVal;
perm = MemoryProtect_MPPA_UX | MemoryProtect_MPPA_UR | MemoryProtect_MPPA_SX | MemoryProtect_MPPA_SR; //even if we are using MPAX, these defines are still ok to use
//Configure the region to protect: XMPAXL10 regs (10 is an arbitrary pick)value=(UINT32)(0xC03B0<<12) + 0x13;ptrMpax=(UINT32*)0x08000050;*ptrMpax=value;ptrMpax=(UINT32*)0x08000054;value2 = (UINT32)(0xC03B00<<8) + perm;*ptrMpax=value2;
//read and write to protected region to try to cause an errorptrVal=(UINT32*)sharedMemoryProgramStart;tempVal=*ptrVal;*ptrVal=tempVal;
//reading XMPFAR, XMPFSRptrMpax=(UINT32*)0x08000200;value = *ptrMpax;ptrMpax=(UINT32*)0x08000204;value2 = *ptrMpax;
I got 0x08000050 from XMPFAR and 0x110 from XMPFSR. Seems like it was complaining about the write to XMPAXL10 reg??
In reply to hy:
I thought offset 0x50 is MPAXL, it is replacement address with permission. offset 0x54 is MPAXH, it is 32-bit address + segment size. You did the opposite way, please double check.
Also, there shouldn't be any issue to write to 0x0800_0050, you can juts try to change it in CCS memory window.
You are correct! I did mixed up the XMPAXL and XMPAXH. I fixed the issue and still saw the same problem I mentioned earlier. Note that this code was run on our actual target platform without JTAG support so I could not manipulate the registers easily through CCS.
//Configure the region to protect: XMPAXH/L10 regs (10 is an arbitrary pick)value=(UINT32)(0xC03B0<<12) + 0x13;ptrMpax=(UINT32*)0x08000054;*ptrMpax=value;ptrMpax=(UINT32*)0x08000050;value2 = (UINT32)(0xC03B00<<8) + perm;*ptrMpax=value2;
value is 0x8000054 for XMPFARvalue2 is 0x00000110 for XMPFCRSeems like there is some kind of fault when I wrote to the XMPAXH10 register??
How are you running your program? The MPAX is inside C66X corepac and should be able to access from C66X CPU.
The program is part of a larger DSP binary that resides on the 2-MB shared memory within location 0x0C03B000 to 0x0C03B000 + 0x0001ce20. The binary is downloaded/run by ARM using mpm_load() and mpm_run().
When using MPM, the code is downloaded from Linux to DSP core then let DSP core run. I am not aware of any restriction to write access to corepac registers. Did read work? Did another MPAX pair work?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.