Enabling BIOS 6.x Exception and MemoryProtect modules

Hi Jonathan,

If you have Exceptions enabled, the exception handler should get called. The libType used to build your application does not have any effect on the Exception module.

Jonathan White said:

var MemoryProtect = xdc.useModule('ti.sysbios.family.c64p.MemoryProtect');

var Exception     = xdc.useModule('ti.sysbios.family.c64p.Exception');
Exception.exceptionHook = '&My_ExceptionHandler';
Exception.enableExternalMPC = true;
Exception.enablePrint       = true;

These settings look fine. I would like to build an example using your .cfg file and reproduce the issue on my end. Can you post your .cfg file ? Also, what version of BIOS are you using ?

Best,

Ashish

Hi Ashish, thanks for responding. We are using ccsv5.1 with bios_6_32_05_54.

I have pasted our .cfg file below. With that version, our My_ExceptionHandler' is not invoked.

If I just un-comment the line "BIOS.libType = BIOS.LibType_Custom" and rebuild everything, then My_ExceptionHandler' is invoked correctly.

Regards, Jonathan

----------

var Hwi = xdc.useModule('ti.sysbios.hal.Hwi');
var CpIntc = xdc.useModule('ti.sysbios.family.c66.tci66xx.CpIntc');
var Startup = xdc.useModule('xdc.runtime.Startup');

xdc.useModule('ti.bios.SYS');
xdc.useModule('ti.bios.LOG');
xdc.useModule('ti.bios.SWI');
xdc.useModule('ti.bios.CLK');

// for CPU Load calculations
var idle = xdc.useModule('ti.sysbios.knl.Idle');
idle.addFunc("&My_IdleLoopCallback");


var MEM = xdc.useModule('ti.bios.MEM')
MEM.STACKSIZE = 0xa000;

var TSK = xdc.useModule('ti.bios.TSK');
TSK.STACKSIZE = 8192;

var MEM  = xdc.useModule('ti.bios.MEM');
MEM.ARGSSIZE = 0x0;

var BIOS = xdc.useModule('ti.sysbios.BIOS');
BIOS.heapSize = 0x8000;

/* System stack size (used by ISRs and Swis) */
Program.stack = 0xa000;


/* to override linker layout */
Program.sectionsExclude = ".*";



/* xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*/
/* IPC Optimization options from TI-Forum Begin */

/* Enables Exception and MemoryProtect */
/* BIOS.libType = BIOS.LibType_Custom; */

/* IPC Optimization options from TI-Forum End */
/* xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*/


var MultiProc = xdc.useModule('ti.sdo.utils.MultiProc');
MultiProc.setConfig(null, ["CORE0", "CORE1", "CORE2", "CORE3"]);

/* Modules explicitly used in the application */
var NotifySetup = xdc.useModule('ti.sdo.ipc.family.c647x.NotifySetup');
NotifySetup.dspIntVectId = 8;
/* NotifySetup.dspIntVectId = 5; */

var Notify      = xdc.useModule('ti.sdo.ipc.Notify');
Notify.numEvents = 16;


var MessageQ    = xdc.useModule('ti.sdo.ipc.MessageQ');
var Ipc         = xdc.useModule('ti.sdo.ipc.Ipc');
var HeapBufMP   = xdc.useModule('ti.sdo.ipc.heaps.HeapBufMP');
var SyncSwi     = xdc.useModule('ti.sysbios.syncs.SyncSwi');

/* Synchronize all processors (this will be done in Ipc_start) */
Ipc.procSync = Ipc.ProcSync_PAIR;

/* Shared Memory base address and length */
var SHAREDMEM           = 0x0C1C0000;
var SHAREDMEMSIZE       = 0x00010000;


/*
 *  Need to define the shared region. The IPC modules use this
 *  to make portable pointers. All processors need to add this
 *  call with their base address of the shared memory region.
 *  If the processor cannot access the memory, do not add it.
 */
var SharedRegion = xdc.useModule('ti.sdo.ipc.SharedRegion');
SharedRegion.setEntryMeta(0,
    { base: SHAREDMEM,
      len:  SHAREDMEMSIZE,
      ownerProcId: 0,
      isValid: true,
      name: "DDR2_RAM",
    });

/* Create a semaphore with count 0 */
var Semaphore = xdc.useModule('ti.sysbios.knl.Semaphore');

var MemoryProtect = xdc.useModule('ti.sysbios.family.c64p.MemoryProtect');
var Exception     = xdc.useModule('ti.sysbios.family.c64p.Exception');
Exception.exceptionHook = '&My_ExceptionHandler';
Exception.enableExternalMPC = true;
Exception.enablePrint       = true;


/*
 *  @(#) ti.sdo.ipc.examples.multicore.evm667x; 1, 0, 0, 0,22; 1-20-2011 10:15:37; /db/vtree/library/trees/ipc/ipc.git/src/ ipc-f23
 */

Startup.resetFxn = "&My_StartupReset";

Hi Jonathan,

I was not able to repro the problem. I need some more information from you to be able to help you.

Jonathan White said:

I have pasted our .cfg file below. With that version, our My_ExceptionHandler' is not invoked.

If I just un-comment the line "BIOS.libType = BIOS.LibType_Custom" and rebuild everything, then My_ExceptionHandler' is invoked correctly.

When you say "My_ExceptionHandler" is not invoked, does that mean that the exception is never taken ? Or, the exception gets taken (you get the register dump print out) but your hook does not get called ?

Also, there is a generated .c file in your application folder that I would like you to post. I have attached an example screenshot to help you find it in your project folder:

You might need to search in Release folder instead of Debug depending on your build configuration.

Best,

Ashish

Hi Ashish, thanks for your reply. I've sent our ...pe66.c file to you via our customer support contact (Juan Gonzales).

How can I view the exception register dump in CCS? I don't see anything in the Console window even in cases when I know we get an exception.

Is there any other way of knowing if we got an exception?

Normally I don't connect CCS until after the exception, because connecting CCS halts a core which causes all the other cores to assert in our system.

[BTW, we are using C6604 (almost identical to C6678)]

Hi Jonathan,

I looked at the .c file you sent me. It looks like the Exception Handler is being properly registered in the vector table.

Since you connect to CCS only after the exception occurs, the console window will not show anything. You can have a look at the Exception module view in ROV to confirm if an exception occured and was handled correctly. I have pasted a screenshot below that shows which Module view to select from ROV. In the screenshot, you can see after an exception occurs, the Exception Context shows the Register dump. If you see a similar Exception Context in your ROV, then the exception handler ran. Please try this out and let me know what you see.

Best,

Ashish

Hi Ashish, sorry for the long delay.

What I see in ROV under Exception is "No data to display", and my exception handler is not called.

Then when I repeat the experiment but with "BIOS.libType = BIOS.LibType_Custom;" in the .cfg file, I see the correct Exception Address in ROV with "Decoded=ExternalException".

The exception number is 0x7A (i.e. L1 data cache, CSL_GEM_DMC_CMPA on Keystone device such as C6678 or C6604). I can see in CCS by looking at the EXPMASK registers at 0x018000C0 (in both cases) that Exception_evtExpMaskEnable has been invoked to enable the exception.

What should I do to solve this problem? [We don't want to use BIOS.libType = BIOS.LibType_Custom]

Jonathan,

In the case where BIOS.litType != Custom, do you see that the Exception is taken?

I'm trying to understand whether the exception happened and your exception hook just didn't get called or the exception didn't happen at all.

Could you put a breakpoint on ti_sysbios_family_c64p_Hwi1? and do you see the breakpoint getting hit?

Judah

Judah, thanks for your reply.

I'm unable to place a breakpoint, as explained earlier in the thread (Sept 11 at 6:04pm) because connecting CCS at that stage kills our system.

So I used ROV (as suggested by Ashish on Sept 11 at 8:46pm above) to look at the Exception data: ROV indicated that in the "BIOS.libType = BIOS.LibType_Custom" the exception clearly was taken and my handler was called. The TI ROV module correctly recorded the fault address.

But in the other case (BIOS.libType not equal to BIOS.LibType_Custom), not only was my handler not called, but it looks like probably the exception was not even taken at the hardware level, since TI ROV did not record any fault address.

I am currently trying to look at the hardware configuration registers and event flags, etc, to see what is different, but my code is the same in both cases, the only difference is BIOS.libType, so I really need some guidance from TI.

Regards, Jonathan

Jonathan,

Its hard to know what could be going on.  My first inclination is that your ISR stack isn't big enough.

I assume you know what is causing the exception in the Custom case?

The Custom case is actually more optimal than the regular case.  But there's nothing else that is inherently different.

Judah

Hi Judah, from my .cfg file (which I posted earlier in the thread), I will assume these lines control the ISR stack size, and I will try increasing it:

    /* System stack size (used by ISRs and Swis) */
    Program.stack = 0xa000;

I'm generating the exception deliberately. I have enabled various kind of memory protection, which I am now testing. I have made a block of MSMC execute-only, using the XMC-MPAX unit in the CorePAC. Then I try to read that memory. The exception (in Custom case) is generated by the L1Data cache controller (which has stored the access permissions). It is exception event CSL_GEM_DMC_CMPA, with value 0x7A.

Next I will be checking the Event Flags, etc., to see if Event 0x7A is pending or any other strangeness like that, I've already checked that it is enabled in hardware at the Exception Event Flag level.

Regards, Jonathan

Jonathan,

If possible, can you post your code that sets up the memory protection and generates the exception?

I would like to try to reproduce the problem here.  I think Ashish was not able to reproduce the problem.
I think you've already posted your .cfg file here.

Judah

Hi Judah, I just tried increasing Program.stack from 0xa000 to 0xd000 (that's the most I have room for), but it did not help.

I will email some code snippets to you via our field support engineers (I can't post them publicly for copyright reasons).

Regards, Jonathan

Hi Judah, I think I have found out what is going on.

The standard BIOS is a super-set of the Custom BIOS we are using, and this standard BIOS seems to run some extra code at initialization time that makes an illegal access to address 0x0184A280, which is 4 bytes beyond the last Level 2 Memory Protection Page Attribute Register (L2MPPA31). This happens before we have enabled exception event 0x7A (L1D cache memory fault exception).

So there is an old memory fault left in the L1D memory protection unit which seems to prevent any subsequent memory fault from being reported.

The workaround for us will be to invoke the following functions to clear all the memory protection units just before enabling the exceptions:

CSL_XMC_clearFault();
CSL_MEMPROT_clearL2Fault();
CSL_MEMPROT_clearL1DFault(); // <-- This is the one that really fixes the problem
CSL_MEMPROT_clearL1PFault();

Longer term, it looks like there is an illegal access in BIOS that should really be fixed.

Regards, Jonathan