TMS320F28P650DK: Group 9 interrupt not triggered due to PIEACK not cleared

Hi Hang,

If they are using interrupt nesting, can you have them list all the interrupts being used in the system and how they are being nested? See my guide on interrupt nesting here - it is important to identify which type of nesting they are doing and which case it falls into. If nesting is implemented incorrectly, it can cause unexpected behavior like this. 

Best Regards,

Delaney

Hi Delaney,

Thanks for the detailed info. Their use case is case 3 (lowest), their ISR is different to the recommended one. I would request them do change according to the recommendation

Nevertheless, could you please give more explanation on how their ISR operation can lead PEIACK set but IFR not set?

Regards,

Hang

Hi Hang,

Let me look into this and get back to you.

Best Regards,

Delaney

Hi Hang,

When an ISR is branched to in a normal (non-nesting) case, the following steps happen:

1. Hardware – Before interrupt propagates to CPU
   1. PIEACK is opened as soon as a signal passes through and IER is set
2. Hardware – After interrupt propagates to CPU
   1. IER register + INTM bit pushed to stack
   2. Clear IFR
   3. Clear IER
   4. Open INTM
   5. Fetch vector
   6. Clear PIEIFR
3. Software
   1. [Interrupt execution]
   2. Close PIEACK 
4. Hardware
   1. IER popped from stack
   2. INTM popped from stack (closed)

The IFR will be cleared automatically by hardware when an ISR is branched to. The ACK also gets opened (set) automatically by hardware. 

It's hard to say how the ACK is being left opened without understanding all the interrupts enabled, the user-defined priority, and how they implemented nesting in each ISR.

Best Regards,

Delaney

Hi Delaney,

Delaney Woodward said:

So, based on the state of the PIE flags, it looks like an interrupt was nested inside the SCI interrupt (or a different interrupt in group 9) between steps 2b and 2f and never comes back to resume the execution.

In the group 9, SCI TX and RX interrupt is also enabled. The SCI RX is the interrupt I refer to "SCI interrupt" previously. 

The TX and RX interrupt are both implemented as the code snippet in the first post

ISR(){
    EINT; // Yes they uses nesting
    DoSomething();
    Clear_SCIA_InterruptFlag();
    Clear_ACK(Group9);
    DINT;
}

The interrupt in the background (including ones in other groups) all shares the same implementation. 

Is it possible to give a explanation on how this implementation can lead to this issue? Or, could you give an example of how this can happen?

Regards,

Hang

Hi Hang,

I will provide a response back tomorrow.

Best Regards,

Delaney

Hi Hang,

Apologies for the delay. I don't believe the difference in order of DINT and the ACK clear should make any difference as the ACK will take more than one cycle to take effect anyway, so the DINT should take effect first in their implementation as well. 

To clarify- they aren't changing any of the PIEIER, PIEIFR, IER or IFR registers in any of the ISRs, is that correct? If so, the priority scheme is the same as in the PIE table, meaning that the SCI interrupts have a pretty low priority being in group 9.

1. Can they verify that the other ISRs in their system are working properly when the SCI interrupt stops getting branched to?
2. It could be that the other ISRs in higher priority groups are blocking the SCI interrupt from ever finishing executing. Are they able to test with a unique GPIO toggle in every ISR and scope which ISRs are being branched to when the behavior takes place?

Best Regards,

Delaney

Hi, Delaney,

There are 4 INTs in the lowest PIE priority Group9, SCI A RX/TX INT, SCI B RX/TX INT.

There is no Enable IER of current group, no clear ACK of current PIE[if ACK exists], no wait 1 cycle before EINT, what problems will occur without these three steps?

Hi Helen,

The steps outlined in the screenshot you sent only apply to the single ISR with the lowest priority, which would be SCIB_TX. The only issue with not clearing the ACK + NOP before EINT is that other interrupts in the same group cannot be nested inside (SCIA_RX, SCIA_TX, and SCIB_RX). I believe missing the IER enable step could cause some issues though because the IER will be cleared automatically during the process of branching to an ISR. Let me do some more brainstorming to understand what those issues would be.

Best Regards,

Delaney

Hi, Delaney,

This indicates that the signal propagation from PIEIFR9.1 to IFR9 is blocked due to PIEACK9 is set.

We then tried resetting SCI-A by software, but it SCI communication is not restored.

After that, we cleared the PIEACK9, and the communication has restored (the interrupt can be entered properly)

It seems that it;s PIEACK9 is set out of the interrupt unexpectedly that causes this issue.

At this case, I think the IER is right, only PIEACK keeps 1. 

Hi Helen,

I see, yes. Could they provide a list of all the interrupts they have enabled and confirm if they use the same below structure for every ISR?

ISR(){

1. EINT; // Yes they uses nesting
2. DoSomething();
3. Clear_SCIA_InterruptFlag();
4. Clear_ACK(Group9);
5. DINT;

}

My guess here is still that a different interrupt is being nested between line 1 and 4 in the above and blocking the CPU from every coming back to finish execution. Because of this, the ACK is left open and no future interrupts for the group ever come in. It would be helpful to understand the nature of the other interrupts in the application.

Best Regards,

Delaney

Hi Delaney,

Delaney Woodward said:

blocking the CPU from every coming back to finish execution.

How can a nested interrupt cause this? the CPU should always come back to previous ISR when the nested ISR is finished (Unless the CPU is stuck in the nested ISR forever), right? Any example what might cause this?

Hi Hang,

Yes for this to happen, I believe the CPU would have to keep nesting forever. It could be that every time the original ISR is branched back to, another higher priority interrupt has already been flagged and propagates to the CPU, so the CPU keeps going into nested interrupts and never completing the original one. 
Let me consult another expert to see if they have any other ideas.

Best Regards,

Delaney

Hi Hang,

Is the customer able to reproduce this issue on more than one of their boards? Can they reproduce the issue on a LaunchPAD/controlCARD? I just want to rule out any hardware issues.

Best Regards,

Delaney

All the ISRs operation are as below:

CPU1 Timer ISR, I2C ISR, SCIA RX/TX ISR, SCIB RX/TX ISR are similar :

Delaney Woodward said:

{

1. EINT; // Yes they uses nesting
2. DoSomething();
3. Clear_SCIA_InterruptFlag();
4. Clear_ACK(Group9);
5. DINT;

}

ADC ISR, IPC1 ISR, IPC2 ISR, IPC3 ISR are similar :

{

1.DoSomething()

2. Clear ACK

}

Hi Helen,

Sounds good, thank you for clarifying the ISR layouts for the other interrupts. Based on this, it looks like interrupts can only be nested inside of the CPU1 Timer ISR, I2C ISR, SCIA RX/TX ISR, SCIB RX/TX ISRs whereas the other interrupts cannot have other ISRs nested inside. Also, are they able to answer this question from above?

Delaney Woodward said:

Is the customer able to reproduce this issue on more than one of their boards? Can they reproduce the issue on a LaunchPAD/controlCARD? I just want to rule out any hardware issues.

Best Regards,

Delaney

Yes, this issue can be reproduced on more than one board. What kind of hardware issue can cause this issue?

Hi Helen,

Ok, I'm not sure what would cause this in hardware, but it always helps just to rule out a hardware problem.  

Delaney Woodward said:

It could be that the other ISRs in higher priority groups are blocking the SCI interrupt from ever finishing executing. Are they able to test with a unique GPIO toggle in every ISR and scope which ISRs are being branched to when the behavior takes place?

Are they able to try the above to rule out any issue with the ISR being blocked by other nested interrupts? Additionally, it would help to have a GPIO toggle in the background loop to verify that it actually breaks out of nesting at some point. 

Best Regards,

Delaney