Internal exception: IERR=0x8 - EVMC6678LE

The exception is for an illegal OpCode.  I'd open a disassembly window at the NRP and see what was there.  Does it look like code or data.

Any number of issues could have cause this, ran off into the weeds because of bad pointer, data corruption, overwrote program space with data due to buffer overflow, etc.  The only way to determine why it happened is to start debugging.  Look at where the CorePac was executing when the Exception occurred (i.e. NRP)  

You may also want to consider using CP_Tracer to trace the program.

Best Regards,

Chad

Hi,

I have exactly the same problem. Every thing works fine with small heap, but with bigger heap, my program crash with the same exception.

In your case, what is the solution ?  

Thanking you in advance,

Jean-Baptiste

I've got a weird error with big heap/stack and the Idle Thread.

Every time I place heap/stack into DDR3 in order to fit my size requirements, some weird problem related to sysbios.knl.task module happens.

So far, I've noticed that disabling the IdleTask at .cfg files seems to solve the problem. But I'm not so sure about that.

Please check my other posts, on a few of them there are more valuable responses from TI staff.

Weber

Hi weber,

Thank for your answer. I use disassembly view right now ... I will try without Idle task.

Thanks,

Could you share here a snap from the disassembly around NPR's location?

I'n my case, the processor jumped into code data, while disassembly the code for similar problem.

I'm still in trouble without Idle task, but no more exception ... Just crash !

I rebuild to have exception and I share here the disassembl around NPR.

Jean-Baptiste

Ok. The disassembly piece of code around NPR should give at least a clue of what happened.

Have you disable using?:

Task.enableIdleTask = false;
Task.allBlockedFunc = Idle.run;

Yes, I use your code on .cfg.

Please find my snap :

makeCrsp:
8357f4e0:   441AB29E     [ B1]  LDBU.D2T2     *+B15[6834],B8
8357f4e4:   44898000     [ B1]  NOP           13
8357f4e8:   44A28000            .word         0x44a28000
8357f4ec:   00000002            NOP          
8357f4f0:   06FC0000            NOP          
8357f4f4:   00000001            NOP          
8357f4f8:   00010000 ||         NOP           9
8357f4fc:   00000032            MPY2.M2       B0,B0,B1:B0
8357f500:   00000003            NOP          
8357f504:   42800000 ||  [ B1]  NOP          
8357f508:   3F800000     [!B0]  NOP          
8357f50c:   FFFFFFFB            .word         0xfffffffb
8357f510:   00010001 ||         NOP           9
8357f514:   0000     ||         ADD.L1        A0,A0,A0
8357f516:   0000                ADD.L1        A0,A0,A0
8357f518:   03201861            DADD.S1X        0,B9:B8,A7:A6
8357f51c:   E4000001            .fphead       n, l, W, BU, nobr, nosat, 0100000b
8357f520:   CCCD                LDW.D2T1      *B15[6],A4
8357f522:   3E4C                LDBU.D1T2     *A4++[2],B4
8357f524:   3E4CCCCD ||  [!B0]  LDH.D2T1      *+B15[19660],A28
8357f528:   100F1413 ||         CALLP.S2      __strasgi_64plus (PC+30880 = 0x83586dc0),B3
8357f52c:   3851B717 ||         .word         0x3851b717
8357f530:   0000     ||         ADD.L1        A0,A0,A0
8357f532:   8F32     ||         MVK.S1        172,A6
8357f534:   023C9058 ||         ADD.L1X       4,B15,A4 

makeCrsp is one of my function, and if I use L2SRAM rather than DDR3, it works fine. The exception looks appear during NOP ... That is weird !

Thanking you in advance if you have any idea

Once NOP stands for No Operation Performed, I also have no specific idea about the error.

However, one thing crossed my mind: To where the processor goes after a NOP instruction? I'm not much a assembly guy, but IF it goes to the next instruction it will rise a crash, because the next instruction is data definition (.word). Maybe the TI's assembly language tools users guide answers it.

The assembly user guide for C66 is SPRU186V.8484.SPRU186V.pdf

If you open a new thread to this problem, please let me know, I want to follow the discussions.

Weber

I remove my last question ;) It is obvious.

I see that one TI employe talk about L2 Cache. I am going to make some try without L2 cache

Just check my other post: http://e2e.ti.com/support/embedded/bios/f/355/p/187339/674520.aspx#674520

There it is well-enough explained a TI's guy.

Weber

Hi,

I've checked it. The processor goes to the next instruction.

Once .word isn't a valid processor instruction, the system crashes just as mine that I've reported on the other post.

Weber

The debugger shouldn't report the overflow prior to the final error?

Weber,

These are not HW buffers (Heaps, Stack, etc)  These buffers are using memory in the same space as everything else that's out there in DDR in this case.  There's nothing to prevent you from overflowing the buffer, you need to make it sufficiently large.  I'd guess the reason you didn't see it when you moved code to another space, is you left the buffer out in DDR, hence the overflow didn't affect anyone.

Note, this is why I suggested to take a look at the dissassembly.  So you could see if it was garbage or not, as this was one of the reasons you would have had the failure, that is executing invalid opcodes which is what the error message was.  Either it jumped to an area with garbage code, or something overwrote the code w/ garbage.

Best Regards,
Chad

Chad,

At this post (http://e2e.ti.com/support/embedded/bios/f/355/p/187339/674733.aspx) I've started to think about a possible relation between moving heap/stack/code into DDR3, this problem and the IdleTask. My disassembly looks just as the one from Jean-Baptiste: Processor running garbage instructions.

It happens ALWAYS when we need big (~8Mb) heap space for each processor and big code sections, which requires moving these sections into DDR3.

Disabling the IdleTask for my case seems to solve the problem, but the same kind of error and disassembly continues to happen.

Please take a look at the other post and share your thoughts there.

I can share my liker.cmd and memory map if you like.

Weber

Chad,

You're right. It is really different at load time. So I am going to looking for overflow trouble.

Thank you very much for your help.

Best regards