Instruction fetch exception errors

Feng,

The disassembly window shows the area of the crash.  The register dump shows A3 contains 0x10606, and the instruction fetch exception shows 0x10604 (which is 0x10606 rounded down to a 32-bit instruction boundary).  Register B3 is consistent with this - the code is calling a function via the A3 register, and part of the function call sets up B3 with 0x0c0de4a4 as the return pointer.

The function being called is *rcvfunction (which you can *barely* see from source code at the top of the disassembly window).  That doesn't look like SYS/BIOS or IPC code (not in the coding style used by those).  Since it's a function pointer from memory, someone might have overwritten the intended function pointer.  Can you trace the code backwards to see a way that *rcvfunction can get corrupted?

It appears that all cores are sharing a common code image in MSMC memory, and using local L2 SRAM for stack/data.  There might be some interaction with CCS going on here, such as a S/W breakpoint for one core messing up other cores (since S/W breakpoints involve actually overwriting assembly code and restoring the original code later).  Things can get complicated when cores share code.

Regards,

- Rob

Feng Jin said:

1. According to what you guide me, I want to make things clear firstly.

Do my codes call a function (address=value of A3) and return to address (value 0f B3)?

But A3 is a invalid address, so the codes dump! Am I right?

Yes, your source code calls (*rcvfunction), and since it is a function pointer the compiler chooses to use register A3 for the branch to the function (i.e., A3 represents the function pointer variable 'rcvfunction').  On the C6x architecture, B3 is used for the function return address.  Since A3 is somehow loaded with a bad address, the "codes dump" when executing the assembly instruction:
    B.S2X     A3

Feng Jin said:

2. Rcvfunction is my processing code. I will try to analysis the function rcvfunction to find the bug!

Yes, you should analyze the code that is assigning rcvfunction.

Feng Jin said:

3. Yes. In my project, the .text is put into MSMCSRAM and the stack and data are put into L2SRAM because the stack and data per core consume almost 600KB. 

If I put the stack and data of all 4 cores into MSMCSRAM, they will consume almost 4*600KB but the MSMCSRAM is not enough.

I use one project with the same .cfg file and all the 4 cores use the same codes. I load the same .out file into per core.

Is my memory configuration(put .text into MSMCSRAM and put .stack/data into L2SRAM) OK?

Or could you suggest me a better way to configure these sections?

The way you're doing is a good way.  If data/stack were to be put in MSMC then you wouldn't be able to use the some .out file for all cores.

I mentioned the MSMC common code and CCS since I wasn't sure that a CCS operation on one core might affect the other cores.  The systems and applications I usually work with have separate code for each core (although it might be a common .out file, but separately loaded into per-core L2), so if CCS modifies the code to set a core's breakpoint it can't affect other cores.  But with common code in MSMC, if you set a breakpoint for one core then it will be set for all the cores (that is for a S/W BP, a H/W BP is not shared this way).  Often CCS is configured to automatically "run to main()" when you load a program, and that is accomplished by CCS automatically putting a S/W breakpoint on main().  With common code all cores will have this BP.

Regards,

- Rob