TMS320F28335: Unexpected interrupt group disable

Paloma,

How are you setting up the ISR? Are you using Hwi to plug the vector table? Can you attach your .cfg file?

Todd

Thank you for your response. CFG file is attached but all identifiers have been modified. The one with the issue is Pwm_EPWM1_INT_ISR.

Best regards.

Paloma

CFGSimp.cfg

Hi Paloma,

Do you happen to be using Hwi_disableIER()/Hwi_enableIER()/Hwi_restoreIER() anywhere in your code?

Also possibly unrelated, you seem to be using the C28 target; The HwiParams.priority field is not supported on C28 so setting it shouldn't do anything on your device.

-Kevin

Hello, I have generated *rl output files, and there isn't any call to Hwi_disableIER()/Hwi_enableIER()/Hwi_restoreIER().

Could HwiParams.priority has any unexpected effect? Should I set that parameter to -1?

More information, when the ISR is called, a SWI is posted. Because I know that IER.INT3 is disabled when the issue happens, could this SWI somehow being in a state that prevents the ISR of finishing? Could another SWI interrupt this SWI and stop the execution of the ISR? Is there any way to debug this?

Besides, I have checked SWI documentation, and in Min 6:31 of http://www.ti.com/download/trng/multimedia/dsp/OLT110026/swis.mp4 says:

if ISR posts a higher priority SWI, the scheduler, will run that SWI immediately in the context of the HWI.

I understand the situation, but how could we set a SWI with a higher interrupt of than a HWI?? Can I check that?

Paloma

Could HwiParams.priority has any unexpected effect? Should I set that parameter to -1?

You should just remove the HwiParams.priority settings altogether, they are not used for C28 Hwi.  Setting them to any value gives the false impression that they are doing something.

More information, when the ISR is called, a SWI is posted. Because I know that IER.INT3 is disabled when the issue happens, could this SWI somehow being in a state that prevents the ISR of finishing? Could another SWI interrupt this SWI and stop the execution of the ISR?

Technically, the Swis can’t run until the Hwi ISR finishes, so there is no “prevents the ISR of finishing” since it’s already finished.  Under the covers, though, while the user’s Hwi function has finished completely, the C28’s SYS/BIOS dispatcher is still running and it then invokes the Swis.  There is still the unrolling of the interrupt to happen, but interrupt masking has been undone so IER.INT3 should have been restored by the time Swis run.

Besides, I have checked SWI documentation, and in Min 6:31 of http://www.ti.com/download/trng/multimedia/dsp/OLT110026/swis.mp4 says:

if ISR posts a higher priority SWI, the scheduler, will run that SWI immediately in the context of the HWI.

I understand the situation, but how could we set a SWI with a higher interrupt of than a HWI?? Can I check that?

That statement applies to a system that is *not* using Hwi to process interrupts, and illustrates the bad thing that will happen if a Swi is posted from this non-SYS/BIOS ISR (note that it says “ISR” in the thread block, not “HWI” as in the previous slide).  That statement ends with “not good”.  This situation can’t happen in a properly constructed SYS/BIOS app.

Is there any way to debug this?

I would be inclined to sprinkle code in key places that checks the state of IER.INT3, in order to determine at what point it becomes permanently disabled.

-Kevin

From what I know, I see 2 options:

1. Our code is disabling the IER.INT3 somehow. You suggest to sprinkle the code with IER.INT3 but, once I know that IER.INT3 is disabled before it should, how could I know what line has been the responsible? Maybe I am missing some information about how to do that. Meanwhile, due to this way of communication takes forever, and this is a severe issue that we need to solve as soon as possible, I will check IER.INT3 value in all HWIs, SWIs and tasks (including Idle). Maybe this gives us some additional information.
2. SYS/BIOS is disabling the IER.INT3 somehow under our code. What I suggest is if SWI_post, no the execution of the SWI, can be blocking de ISR somehow. That would be, the execution enters in the ISR, and at the time to make the post, the post gets struck and the execution of the ISR stops. That would explain that IER.INT3 is disabled. Is there any SWI attribute I could check to know if the post has been done successfully?

Thank you very much.

Paloma

From what I know, I see 2 options:

1.     Our code is disabling the IER.INT3 somehow. You suggest to sprinkle the code with IER.INT3 but, once I know that IER.INT3 is disabled before it should, how could I know what line has been the responsible? Maybe I am missing some information about how to do that. Meanwhile, due to this way of communication takes forever, and this is a severe issue that we need to solve as soon as possible, I will check IER.INT3 value in all HWIs, SWIs and tasks (including Idle). Maybe this gives us some additional information.

By checking the state at different points in your code, you should be able to narrow down where the disable occurs. You can then step through the code to determine the exact line or try new locations to narrow it down even further.

 2.     SYS/BIOS is disabling the IER.INT3 somehow under our code. What I suggest is if SWI_post, no the execution of the SWI, can be blocking de ISR somehow. That would be, the execution enters in the ISR, and at the time to make the post, the post gets struck and the execution of the ISR stops. That would explain that IER.INT3 is disabled. Is there any SWI attribute I could check to know if the post has been done successfully?

You can set breakpoints and check the trigger value of your SWI_Handle through CCS or <Swi_Handle>->trigger to see if your SWI has been successfully posted during your execution.

-Kevin