TMS320F28335: unintentional interrupt mask

Hi,

Thanks for your question!

Is your application using nested interrupts by any chance? If so, this could potentially be related to the known errata (document here) where spurious nested interrupts can occur in a few situations. Please check if anything in the following section applies to your application (then we can debug from there for a workaround):

"Usage Notes and Known Design Exceptions to Functional Specifications"->"Usage Notes"->"PIE: Spurious Nested Interrupt After Back-to-Back PIEACK Write and Manual CPU Interrupt Mask Clear Usage Note"

-or-

"Usage Notes and Known Design Exceptions to Functional Specifications"->"Usage Notes"->"Caution While Using Nested Interrupts"

Other than this, the other thing to make sure of is that the PIEIER, IER, and INTM for this interrupt are not being modified in other locations (or right before this interrupt). If another piece of code blocks off the PIEIER, IER, or INTM from propagating the interrupt, then that could be the cause.

Additionally, particularly if using nested interrupts, please ensure that the ISR of an interrupt in one group does not modify the PIEIER of another group. For example, an ISR in group 2 should not modify the PIEIER in group 1. This can cause spurious interrupts to occur.

Let me know if the errata applies to your application, as other than the items mentioned above, there should be no possibility of a PIEACK call being ignored.

Regards,

Vince

Thank you for your reply!

Yes, my application is using nested interrupt.
I use XINT, TINT0(CPU-Timer0), CPU-Timer2, SPI-Rx, and SPI-Tx for interrupt.
XINT interrupts every 400 micro seconds and CPU-Timer2 interrupts every 10 micro seconds while XINT is interrupting. CPU-Timer0 interrupts every 100 micro seconds. SPI-Rx and SPI-Tx interrupt when a SPI master starts SPI communication.

I knew the errata and I had checked my program code. I had found a wrong code sequence where I enable a global interrupt first and then clear a PIEACK in SPI-Rx interrupt function. That's back-to-back and reverse order. So I changed the code as an example of errata 5.1.1 workaround. But the trouble still happends.

I'm not sure how I can apply the errata 5.1.2, because I do not want any other interrupt during SPI-Rx and SPI-Tx interrupt. So SPI-Rx and SPI-Tx interrupt functions have a global interrupt disable at the begining and have a global interrupt enable at the end. This errata says if I enable interrupts using the EINT instruction in an ISR, then I must disable the interrupts before exiting the ISR. What should I do?

No interrupt modifies the PIEIER or IER of any other group. As for INTM, since this is a global interrupt mask, it is modified in main loop, XINT, SPI-Rx, and SPI-Tx to make other interrupts disable in a short period and afterwords to make them enable back again.

Best Regards,

Toshi

Hi Toshi,

Thanks for taking the time to look into the errata and testing out the workaround!

So since your testing shows that 5.1.1 was not the cause of this intermittent error, let's instead see if errata 5.1.2. can solve the issue:

toshi tat said:

I'm not sure how I can apply the errata 5.1.2, because I do not want any other interrupt during SPI-Rx and SPI-Tx interrupt. So SPI-Rx and SPI-Tx interrupt functions have a global interrupt disable at the begining and have a global interrupt enable at the end. This errata says if I enable interrupts using the EINT instruction in an ISR, then I must disable the interrupts before exiting the ISR. What should I do?

Basically, the errata 5.1.2. requires that right before the exit from the interrupt, that DINT is called. So the code structure would be something similar to the following (may vary depending on interrupt setup):

nested interrupt
{
    //
    // PSEUDO-CODE INTRO STEPS:
    //  * save PIEIER for manual restore at the end of ISR
    //  * modify IER
    //  * Modify this group's PIEIER if needed
    //  * PIEACK
    //
    asm("       NOP");  // <--- This is important, 
                        // so please make sure NOP is there
    
    EINT;               // since we use EINT, errata 5.1.2 applies
    
    
    //
    // Insert ISR Code here.......
    //
    
    
    //***************************************************
    // THIS IS THE CODE NEEDED TO DEAL WITH ERRATA 5.1.2:
    //***************************************************
    DINT; 
    // DINT is used to protect restoring of the PIEIER, 
    // -AND- so the interrupt doesn't cause unexpected 
    // issues as mentioned in errata 5.1.2.
    //***************************************************
    // END OF THE CODE NEEDED TO DEAL WITH ERRATA 5.1.2:
    //***************************************************
   
    // Manually restore the saved PIEIER bits here
}

It is okay to DINT at the end of the ISR, because when the ISR does the return call at the very end, INTM is part of the restore. So INTM is cleared again when the ISR function finishes and returns (allowing more interrupts to run).

See this link (link here) for some more details on the standard interrupt handling, and what is restored automatically during the return.

So definitely make sure to call the DINT at the end of the nested interrupts, to avoid the issue from errata 5.1.2.

Let me know if this clears up the issue for you!

Regards,

Vince

Hi Vince,

Thanks for your link. I understand about the interrupt handling in detail.
Sorry but I haven't tried the errata 5.1.2 yet becase of my application design.
My code configuration of interrupt is like this:

main(){
  interrupt SPI-Rx enable
  interrupt SPI-Tx enable
  interrupt XINT enable
  EINT
  ...
  while(){...}
}

interrupt SPI-Rx(){
  DINT
  ...
  EINT
}

interrupt SPI-Tx(){
  DINT
  ...
  EINT
}

interrupt XINT(){
  EINT
  ...
}

I know I should call DINT right before exit.
Is that mean I should add DINT right after EINT in SPI-Rx and SPI-Tx?
Or I didn't need to call EINT?

Best Regards,

Toshi