Resource conflict exception ti.sysbios.family.c64p.Exception: line 256: E_exceptionMax: pc = 0x00863620, sp = 0x80811320. xdc.runtime.Error.raise: terminating execution

Ganapathi Dhandapani said:

It is a exception error. I think your test application try to access invalid/uninitialized memory section.

It stands right there what kind of exception it is, resource conflict one. Does this kind of exception occur upon memory reference? No[t that I know of]. Actually, can any kind of exception occur upon access to invalid/uninitialized memory section on processor in question? No[t that I know of]. Well, if privileged separation is on, exception can occur from unprivileged code upon reference to privileged section, but this normally wouldn't be classified as "invalid/uninitialized"...

When it comes to resource conflicts first suspect is compiler. Indeed, it's compiler that lays down instructions in conflicting manner. If it's assembly routine, then first to blame is programmer [who again laid down instructions in in conflicting manner]. It might be silicon errata [that needs to be worked around by upgrading compiler and/or specifying correct silicon version at command line]. But in either case memory reference is last thing to consider. What to do? Look at assembly at denoted pc. Identify offending subroutine. Where does it come from? Is resource conflict obvious? If yes, and it's compiler generated, file bug report. If not, dig into silicon errata...

Dear all,

In addition to the aforementioned issue that I fixed,
I get a similar error but the program counter and B3 register have the very strange value 0xBEBEBEBE , that is the value that the is used for stack initialization. This problem is appeared only when I compiler my project in release mode and all are fin in release mode.

The 1/4 of L2 is used for the cache

[C66xx_0] 0x80000000 A31=0x200
B0=0x8000fb48 B1=0x1
B2=0x8000fb48 B3=0xbebebebe
B4=0x820260 B5=0x8bfc80
B6=0x15000103 B7=0x15000103
B8=0x801ae8 B9=0x8cf4d8
B10=0x80f08000 B11=0x807ba4ec
B12=0x90000001 B13=0x80f08040
B14=0x864d20 B15=0x80801d38
B16=0x7928 B17=0xacae
B18=0xf8ae B19=0x1c24
B20=0xffff4642 B21=0xffffcb68
B22=0x0 B23=0xffff8864
B24=0x9c B25=0x7256efbd
B26=0x0 B27=0xffffffff
B28=0x80426b08 B29=0x80427b10
B30=0x3 B31=0x8d1540
NTSR=0x1020f
ITSR=0x20d
IRP=0x8b453a
SSR=0x0
AMR=0x0
RILC=0x0
ILC=0x0
Exception at 0xbebebec0
EFR=0x2 NRP=0xbebebec0
Internal exception: IERR=0x12
Fetch packet exception
Resource conflict exception
ti.sysbios.family.c64p.Exception: line 256: E_exceptionMax: pc = 0xbebebec0, sp = 0x80801d38.
xdc.runtime.Error.raise: terminating execution

Best regards

Dear Rich,
If I understand correctly, the problem that you have was appeared when you change the BIOS?
In our project we use the 7.4v compiler
Is this the correct compiler or we should use the new one

Thanks 

George

The key element in the crash output is address of execute packet that caused exception, "exception at 0xf00d31f4" in last case. Just like with any other platform you start by using this address to identify the problem subroutine. Normally you also examine disassembler output to pinpoint exact cause. Then you ask yourself how did program get there [normally by tracing stack frames back to caller, caller's called, etc.], and if the mayhem could have been caused by "off-charts" parameters passed to the function, and in such case where did they, malformed arguments, come from. But this is in "normal" cases. In abnormal cases, when memory (most likely stack) is corrupted as result of some gross programming error or misconfiguration (like insufficient stack size), it becomes virtually impossible to answer previously mentioned questions, because your program is likely to end up in completely irrelevant and unpredictable place, including portions of memory dedicated for data, rather than executable code. In such case one would expect that "illegal opcode" exception would be more common. This is why I initially said that compiler (or assembly programmer) ought to be first one(s) to blame for "resource conflict" exceptions, but it appears that it can be as common. In Rich's case the suspicion is strengthened by the fact that AMR is not zero. This register is not used by compiler and it being set, especially its reserved portion, to non-zero value suggests that processor did execute something that it shouldn't have executed.

Dear all,
I have been searching this issue for 1 week and today I realized t before the program crashes, a HWI interrupt is occurred and the id of this event is 90, regarding the ROV . I was going through the documents and this is related with the MPU0 addressing violation interrupt and protection violation interrupt, table 8.34 SPRS814B. How can I discover where is this wrong memory access
Best regards
George