• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 960 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.

AM3352: Emulation interrupt EMUINT

Kummi
Mastermind 6220 points

Part Number: AM3352

Hi,

Do we have more details about Emulation interrupt mentioned in TRM's "Table 6-1. ARM Cortex-A8 Interrupts"?

In what condition does this interrupt occur...does this interrupt only occur during debug?
and is it possible to disable this interrupt which occurs frequently during debug?

Best Regards
kummi

  • 0
    TI__Guru**** 393215 points
    The factory team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Mastermind 6220 points
    Please let us know if there is any details on this EMUINT interrupt.
    Actually we are getting this interrupt frequently, don't understand what is this
    interrupt and why does is occur frequently.
    Actually this interrupt occurs even though it is not enabled.

    Best Regards
    Kummi
  • 0 in reply to Kummi
    TI__Guru* 90445 points

    Kummi, this is an interrupt from the ICECrusher debug extension module, which can generate interrupt for various reasons (full trace buffer, cross-triggering, etc.)  You should be able to just mask this interrupt and ignore it during normal operation.

    Regards,

    James

  • 0 in reply to JJD
    Mastermind 6220 points

    Hi James,

    Thank you for the information.

    Unfortunately, we are not able to MASK this interrupt.
    Even though Masking this interrupt through INTC_MIR0 Register, we are still getting the interrupt.

    Please let us know how to Mask this interrupt.

    Ignoring the interrupt is the only option?


    Best Regards
    Kummi

  • 0 in reply to Kummi
    TI__Guru* 90445 points
    Kummi, do you mean that the processor is getting the interrupt? Or you just see the raw interrupt pending in the ITR register? If it is the latter, then that is expected, and the mask will block it from interrupting the processor. If the processor is still getting an interrupt, let me know.

    Regards,
    james
  • 0 in reply to JJD
    Mastermind 6220 points
    Hi James,

    Thank you,

    Actually it seems the processor is getting the interrupt.
    In this application all the unused interrupts are routed to an
    unusedInterrupthandler and we always see this this Interrupthandler
    being called because of this EMUINT interrupt, even though it is masked.

    Best Regards
    Kummi
  • 0 in reply to Kummi
    TI__Guru* 90445 points
    Sorry Kummi, i don't really have an explanation for that behavior. The only other suggestions i can make is to ensure that no other unused interrupt is causing the handler to be executed. Also, be sure the EMUINT is not pending for masking it off.

    Thanks,
    James