• Locked Locked
  • Replies 9 replies
  • Subscribers 119 subscribers
  • Views 5186 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Assertion of IRQS is not causing calling of ISR

Lokesh Kumar
Note: This was originally posted on 4th September 2012 at http://forums.arm.com

Hi,

With my current flow, when I am asserting legacy nIRQ I am able to jump to ISR, but not when asserting IRQS[0].
I have enabled interrupts as below
[size=2]CPSIE   ifa, #18

and configured [size=2]Interrupt Security ([/size][/size][size=2][size=2]ICDISR), [size=2][/size][/size][/size][size=2][size=2][size=2][size=2]Interrupt Edge Trigger Config ([/size]ICDIF),[size=2]Interrupt Priority (ICDIPR)[/size][/size][/size][/size],[size=2]Interrupt Target Processor (ICDIPTR),[size=2]Interrupt Enable (ICDISER),[size=2]Interrupt Priority Mask (ICCPMR),[size=2]Interrupt Binary Point (ICCBPR),[size=2]Interface Control Register (ICCICR),[size=2]Distributor Control Register (ICDDCR)

Am I missing something?
Is something separate need to be done, when using IRQS interrupts?

Thanks
Lokesh
[/size][/size][/size][/size][/size][/size]
Parents
  • Arm Employee Badge
    Note: This was originally posted on 5th September 2012 at http://forums.arm.com

    You haven't said, but I'm guessing you are using Cortex-A9 MPCore - correct me if I guessed incorrectly.

    So the nIRQ signals are the legacy interrupt signals.  When the CPU interface is disabled (ICCICR.Enable=0) the nIRQ is connected directly to the core.  All you need to generate an IRQ exception is clear CPSR.I and then assert the nIRQ signal (*).

    When you enable the IC (ICCICR.Enable=1 & ICDDCR.Enable=1), the cores interrupts are driven by the IC.  The nIRQ line no longer gets connected to the core directly, but becomes just another interrupt source for the IC (a PPI to be precise, with ID 31).

    To take an interrupt connected via the IRQS signal you must enable and configure the IC.  From your earlier post, you seem to programming all the right registers.  Question is what are you programming them to?  You could, for example, be enabling ID31 (the nIRQ ID) but not ID32 (the IRQS[0] ID).

    On your question about vectors.... No, a Cortex-A9 core has only one IRQ vector. 

    * Remembering that nIRQ is active low.  So to "assert" you actually take the signal low.
Reply
  • Arm Employee Badge
    Note: This was originally posted on 5th September 2012 at http://forums.arm.com

    You haven't said, but I'm guessing you are using Cortex-A9 MPCore - correct me if I guessed incorrectly.

    So the nIRQ signals are the legacy interrupt signals.  When the CPU interface is disabled (ICCICR.Enable=0) the nIRQ is connected directly to the core.  All you need to generate an IRQ exception is clear CPSR.I and then assert the nIRQ signal (*).

    When you enable the IC (ICCICR.Enable=1 & ICDDCR.Enable=1), the cores interrupts are driven by the IC.  The nIRQ line no longer gets connected to the core directly, but becomes just another interrupt source for the IC (a PPI to be precise, with ID 31).

    To take an interrupt connected via the IRQS signal you must enable and configure the IC.  From your earlier post, you seem to programming all the right registers.  Question is what are you programming them to?  You could, for example, be enabling ID31 (the nIRQ ID) but not ID32 (the IRQS[0] ID).

    On your question about vectors.... No, a Cortex-A9 core has only one IRQ vector. 

    * Remembering that nIRQ is active low.  So to "assert" you actually take the signal low.
Children
No data