• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 614 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TMS320F28335: unintentional interrupt mask

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

toshi tat
Prodigy 40 points
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?

  • 0
    TI__Guru 62975 points

    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

  • 0 in reply to tlee
    Prodigy 40 points

    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?

  • 0 in reply to toshi tat
    TI__Guru 62975 points

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