Hi all,
when DSPBIOS hang, it will trigger UTL_halt which call from SYS_abort.
So if without CCS, can we have method to get the call stack backtrace from the UTL_halt?
I mean we can hook the UTL_halt function, add some function like backtrace(...), then we can know where the execption happens.
Does is possilbe?
Currently we find out the code where the exception is triggered by setting breakpoint at _EXC_dispatch which is default entry point for all exceptions.
Then check the value of B3 register, which stores the function return address. Any method can do this without CCS?
Our hardware is Omap L138, BIOSDSP version is :5_41_02_14
thanks
JiangPeng
Unfortunately there is no run-time backtrace()-type capability for C6x, and even the CCS capability is limited w/o debug information compiled in.
Buf for the exception situation a backtrace() wouldn't help much, since what it would tell you is already known - EXC_dispatch was called by the NMI/exception handler vector. EXC_dispatch() will call subroutines to print all known exception information. When you reach UTL_halt() due to an exception, you can open a BIOS message LOG and select the Execution Graph Details LOG, where you will find information related to the exception.
If you want to "catch it in its tracks", you can place a breakpoint on the vector itself, at the label "hwi1". When you hit that BP, you can see the NRP register in the CPU Core registers to determine where the PC was executing at the time of the exception (although, NRP is printed in the Executaion Graph Details LOG), and you can see all the register values at the time of the exception (which you won't have if you reach UTL_halt(), since the exception processing has trashed all registers). You would then need to inspect the code pointed to by NRP to gather further information about what caused it. If it is an external exception, and you don't already have it enabled, you can enable bios.MEM.USEMPC=1 in your .tcf file to have the MPC module decode exceptions generated by either of L1D/L1P/L2.
Regards,
- Rob
Hi Rob,
thanks for reply, I am still confused about the exception handler of TIBIOS, we are using the C6747. I run below case to try some exception of bios, found for case 1,2 no utl_abort, for case 3, it will have.
so, may I know in condition can catch exception such as case 1 or 2? set MMU?
case 1: char *p = 0; *p = 30; //no exception
case 2: unsigned long i = 9; *(unsigned long *)i = 10; // no exception
case 3: void (*p)() = myfunc; p = 0; (*p)(); //have exception
btw, we found method to backtrace the call stack of exception 3, share with you:
sys_stk = (Uint32)HWI_data.stkBottom; usr_stk = *((Uint32*)sys_stk - 0x2d); ret_addr = *((Uint32*)sys_stk - 0x21); nrp_val = *((Uint32*)sys_stk - 0x43);
// record function call stack stack_ptr = (Uint32*)usr_stk; func_num = 0; while ((func_num < 8) && ((Uint32)stack_ptr < (usr_stk + 256))) { if ((*stack_ptr >= (Uint32)text_start) && (*stack_ptr <= (Uint32)text_end)) { g_CallStack[func_num] = *stack_ptr; func_num++; } stack_ptr++; }
I believe that if you enable the MPC module then you will see exceptions generated for cases 1 & 2.
To enable the MPC module, do this in your .tcf file: bios.MEM.USEMPC = true;This causes the EXC module to be notified when an exception comes from one of the MPCs (in this case, L1D & L2).
Your backtrace function looks interesting, thanks for sharing that. It might record a false function in the backtrace if there is a local function pointer on the stack.
thank you for your information about enable MPC, it can capture these kind of exception by MPC, but do you know any method can backtrace the call stack?
Or from the MPC moduble, can we locate the user stack location, then we can use our method to walk through the call stack.
Rob
btw, can you share more information about MPC, because the API reference guide is very simple.
From my observation, access Zero address, some un-existed DSP registers will cause the exception from MPC, can you share more kinds of error will generate the MPC exception? we are using OMAP L138.
The MPC exception handling functions are called from within the EXC exception handlers, so any backtrace that works from the context of EXC will also work from MPC context. Your method which tracks the HWI stack from UTL_halt() will also function as well (or as badly) when performed from MPC exception handling context.
BIOS's MPC module will report exceptions originating from the EVT{DMC,PMC,UMC}CMPA events on a C64+ processor. Typically, those events result from a memory access violation when accessing legitimate addresses in the memory space and the access does not have the appropriate characteristics per the MPPA (Memory Protection Permission Attribute). For example, when trying a memory read from a real L2 memory address that doesn't have the "read" attribute set in the MPPA for that address' memory page (permissions are set on a "page" basis, and the page size differs depending on the memory size).
BIOS's MPC module does not program any MPPA registers, that is the responsibility of the application writer, and as a result all MPPAs are "wide open" (i.e., allow any type of access from any source). However, the L1D/L1P/L2 memory controllers will ultimately report an access to a bad address such as 0 (even though they don't control that "address"). The reporting comes in different forms depending on which memory controller originated the request, and I can't really relate the details of the mechanism, but when you enable BIOS's MPC module, any of the 3 types of access to address 0 (code fetch, memory read, memory write) will result in an exception that gets handled by the EXC module (by way of the MPC module hooking into the EXC module "hooks").