This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Instruction Fetch Exception, C6678

Other Parts Discussed in Thread: SYSBIOS

Hello all,

WHen running a load of software on a C6678 with SYS/BIOS 6.32.5.54, some time after startup (sometimes immediately, sometimes after around 10 minutes of normal operation) I receive an Instruction Fetch Exception error and my code exits.  The data that is printed to the console is the following:

B13=0x0

B14=0x86a838 B15=0xc26bd58

B16=0xc268df0 B17=0x0

B18=0x2e30000[C66xx_8] B19=0x0

B20=0x0 B21=0x2e3

B22=0x2e30000 B23=0x0

B24=0x0 B25=0x3000

B26=0x3000 B27=0x0

B28=0x0 B29=0x3

B30=0x640 B31=0x1dcd696e

NTSR=0x1000f

ITSR=0xf

IRP=0x84ad20

SSR=0x0

AMR=0x0

RILC=0x0

ILC=0x0

Exception at 0x1bc94f6

EFR=0x2 NRP=0x1bc94f6

Internal except[C66xx_8] ion: IERR=0x1

Instruction fetch exception

ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0x0084ad20, sp = 0x0c26bd58.

xdc.runtime.Error.raise: terminating execution

In searching for this issue on other posts, I opened up the ROV and looked through the exception handler.  The B3 register stored in the exception is set to 0x00849260, which when looking through the disassembly this address maps to an instruction set labeled $C$RL1.  When examining the disassembly given for NRP, the actual address is a NOP operation, and everything surround it is alternating NOP and SWBP instructions. 

I imagine this is a memory issue somewhere, where a pointer is getting trashed somewhere, but I am having a difficult time tracking down the root cause.  In looking at my Tasks in the ROV nothing appears to be blowing its stack, at least there are no notifications of such and all of the peaks given are below the sizes. Similarly, HeapMem size given appears to have plenty of free size, and the HWI module has a stack much larger than it's given peak. 

As an additional note, I am sometimes receiving Double Free exceptions occurring instead of the exception above, although the code is not completing and free operations, far as I can tell.

I think that's about all of the information I have on it; if anyone has any suggestions on what might be causing this or avenues to approach, I would be greatly appreciative. 

  • Does the exception occur at the same address each time? If you do, you can set a breakpoint a few instructions before the exception occurs to see what is causing it.

    Can you add the following to your cfg file:

    var Exception = xdc.useModule('ti.sysbios.family.c64p.Exception'); // Include if not already present
    Exception.enablePrint = true; // Helps make the exception more readable

    Also, if you can add Memory Protection to your cfg, it should help you catch any memory corruptions:

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

    Regards,

    Gilbert

  • Gilbert,

    It does appear to happen at the same point every time, but when I put a breakpoint in the disassembly around it, there does not appear to be any code that I recognize there).

    I just placed the exception module into my configuration, and when the issue happened again, this printed out (it looks the same to be as previous runs, and nothing strikes me as new in the exception portion of the ROV):

    B13=0x0
    B14=0x86a7b8 B15=0xc26bd58
    B16=0xc268df0 B17=0x0
    B18=0x2e30000 B19=0x0
    B20=0x0 B21=0x2e3
    B22=0x2e30000 B23=0x0
    B24=0x0 B25=0x3000
    B26=0x3000 B27=0x0
    B28=0x0 B29=0x3
    B30=0x640 B31=0x1dcd69f6
    NTSR=0x1000f
    ITSR=0xf
    IRP=0x840fd0
    SSR=0x0
    AMR=0x0
    RILC=0x0
    ILC=0x0
    Exception at 0x1bc94f6
    EFR=0x2 NRP=0x1bc94f6
    Internal exception: IERR=0x1
    Instruction fetch exception
    ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0x00840fd0, sp = 0x0c26bd58.
    xdc.runtime.Error.raise: terminating execution
  • Can you take a look at the call stack? Which functions are being called right before the exception occurs? Is there any corresponding C code to the disassemble you are stepping through?

    Gilbert