Why would F280049 enters the interrupt CLA1_8_ISR()

If I understand, CLA Task 8 is not enabled within the CLA? Yet the C28x takes the interrupt for CLA1 Task 8?  Is that correct?

If you step-through and return from the ISR,  where does the C28x PC return to?  Note you may need to remove an infinite while loop in the ISR stub provided by TI to do this.  This may provide clues as to how the C28x got to the ISR.

Let me know if I have understood the problem statement correctly?

CLA Task 8 is now set as background task to run. And background task is enabled within the CLA.

I use ePWM module to make an 25us cycle interrupt and there is an interrupt service routine to run something. Then in the ISR, I would trigger cla task regularly.

After configuration in the main(), there is an while loop in the end of main(). So, C28X would return to the while loop after retuning from ISR.

Now, I found that if i remove some program in the cla task, the program would not enter the CLA1_8_ISR(). But it still happened if I use the original program.

If possible, I could send you the project to test.

To debug this we need to try and figure out if the C28x really took an ISR for CLA1_8 or if the PC ended up there for some other reason.  Reasons could be, for example, corrupted stack, overflowing buffer, etc. 

Make sure you are using the latest long-term support compiler (currently this is v20.2.4.LTS  C2000-CGT). 

user6531244 said:

CLA Task 8 is now set as background task to run. And background task is enabled within the CLA.

I assume the background task has been started before the while() loop. 

Is it started via a write to MCTLBGRND.BGEN + BGSTART? or is it triggered by a hardware trigger? i.e. MCTLBGRND.TRIGEN?  Note if you use BGSTART then TRIGEN must be set to 0.

user6531244 said:

Then in the ISR, I would trigger cla task regularly.

Is it correct that this is not task 8?  I'll call it Task X.  i.e. Task X will interrupt Task 8. 

Is the Task X the task that you are removing/adding code from? Does Task X interrupt the C28x when it completes?

When you end-up in CLA1_8 ISR

• Is the MSTBGRND RUN bit set?  The background task should just continuously run. 
• If you step-through and return from the ISR,  where does the C28x PC return to?  Note you may need to remove an infinite while loop in the ISR stub provided by TI to do this.  This may provide clues as to how the C28x got to the ISR.

Another thought - is there an MSTOP within the background task?

Now I am using the compiler v18.12.3.LTS.

It is correct that background task starts before while() loop that in the end of main().

The background task starts is via a write to MCTLBGRND.BGEN + BGSTART. The following statements is how I config:

/****start****/

Cla1Regs._MVECTBGRND = (uint16_t)&Cla1BackgroundTask;

Cla1Regs._MCTLBGRND.bit.TRIGEN = 0;//0:trigger by software;1:trigger by peripheral;

DmaClaSrcSelRegs.CLA1TASKSRCSEL2.bit.TASK8 = 0; //Software

Cla1Regs._MCTLBGRND.bit.BGEN = 1;//enable the background task

Cla1Regs._MCTLBGRND.bit.BGSTART = 1;//start the background task

/****end****/

That is not the task 8 and Task X does not interrupt the Task 8.

It is not the Task 8, but there is other tasks(not Task 8) are triggered in timing. Task X would not interrupt the C28X when it completes.

There is an important imformation for you to understand the problem.

When I debug to run the program step by step with breakpoint. In the configuration of device, I find the program runs into the CLA1_8_ISR() after it executes

the statement "EINT" which is to enable global interrupt INTM. And the program never run into the ePWM ISR, the CLA task and the while() loop, but end up

at CLA1_8_ISR.

The following is the CLA1_8_ISR():

/****START****/

interrupt void
CLA1_8_ISR(void)
{
//
// Insert ISR Code here
//

//
// To receive more interrupts from this PIE group,
// acknowledge this interrupt.
//
// PieCtrlRegs.PIEACK.all = PIEACK_GROUP11;

//
// Next two lines for debug only to halt the processor here
// Remove after inserting ISR Code
//
asm (" ESTOP0");
for(;;);
}

/****END****/

No MSTOP within the background task but ESTOP in the CLA1_8_ISR.

I think the reason most probably is the overflowing memory. Because while I comment some statements in the cla task, the program runs normally.

Where could I know whether the CPU or CLA program memory is overflowing.

Hello, 

Please use the code syntaxhilighter when you paste code into a forum post.  It will make it much easier to read.  The button looks like </> on the editing controls.  (see https://e2e.ti.com/support/site-support/f/1024/t/812271)

If you remove the for(;;) loop from the ISR, step through the ISR where does the PC endup?  This could provide clues - is it in valid code?  View the Disassembly window to see if it looks reasonable or if it is littered with things like ITRAP. 

When you hit the ISR, check the stack pointer (SP) - is it within the memory you have allocated for it?  One method to check for stack size is to use CCS to fill the memory with a known value (ex: 0x5a5a) before running the program.  Then, when you hit ISR 8, you can check to see how much of the known value has been overwritten by the stack.  There should still be the known value left over.

user6531244 said:

When I debug to run the program step by step with breakpoint. In the configuration of device, I find the program runs into the CLA1_8_ISR() after it executes

the statement "EINT" which is to enable global interrupt INTM. And the program never run into the ePWM ISR, the CLA task and the while() loop, but end up

Right before you execute the INTM, check the enables and flags to see if CLA ISR 8 is set.  If it is then it may not be a buffer problem.  If it is, then the question is when did this happen - how did it get set.  

You mentioned the CLA 8/background task is not run - have you checked this with a pin toggle or breakpoint in the CLA 8 task?

Please also try this with the latest compiler.  

-Lori