This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28335: ISR of XINT started under the unintentional interrupt mask condition

Part Number: TMS320F28335

Related question to "unintentional interrupt mask" I posted before. In that case, PIEACK of XINT was not cleared because of INTM usage violation (errata usage note 5.1.2). There was one more strange thing which is that the ISR of XINT was started even PIEACK is not cleard after about 300 micro seconds at the same time when an ISR of SPIRXINTA is called. Did this happen due to INTM usage violation also? Did it last that long? Or did the ISR of SPIRXINTA remove the blockage somehow?

  • toshi tat,

    From a hardware interrupt perspective, I do not see how the SPI interrupt would unblock a pending XINT interrupt. The PIEACKx for XINT should continue to mask the interrupt.

    However, since you are using software-based interrupt nesting, which suppresses the normal hardware interrupt behavior, I suppose it is possible that the nesting software could have detected the pending XINT PIEACK status and executed the ISR through the custom interrupt dispatch software.

    -Tommy

  • My application doesnot do such thing to detect and remove the pending PIEACK of other group. But, as for as I see, everytime this PIEACK trouble happended, XINT restarted right after the SPI interrupt routine. If it can not be explained, should I believe affection of INTM usage violation is remaining?

  • I suppose it is possible that the INTM violation is allowing the XINT interrupt to propagate.