• State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 350 subscribers
  • Views 926 views
  • Users 0 members are here
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

GICv3 ICC_EOIR

Grace WANG

Hi

When I test Cortex-R52 with GIC500 (GICv3), I find an issue.

The interrupt is handled by the following order:

1. save context

2. read ICC_IAR0, get INTID

3. jump to ISR of the associated INTID

4. write ICC_EOIR0

5. restore context

The IRQ is unmasked before writing ICC_EOIR0.

When an IRQ is triggered frequently, I find the CPU will never goes to the last step - restore context. Could you explain the reason for that ?

BR, Grace

Parents
  • 0 in reply to Martin Weidmann

     Hi Martin

    Per tests, I agree with you. 

    Besides, I have some other questions from tests.

    What I do is as follows:

    1. configure and enable a FIQ with priority 0 and an IRQ with priority 10.

    2. at the end of FIQ callback enable FIQ and IRQ (CPSR.I and F = 0)

    3. for some particular timing, before writing ICC_EOIR0, the IRQ asserts and the CPU goes to irq exception but the returned INTID is 1023.

    From the CPU interface registers: ICC_RPR is 0 that is the FIQ, and ICC_HPPIR1 is the IRQ ID. I think in this case, while entering irq exception, the CPU interface finds the HPPI IRQ has not sufficient priority as its priority 10 is lower than the active FIQ priority 0. So the special INTID 1023 (IRQ) is returned.

    And if FIQ has lower priority 10 and IRQ has higher priority 0, the similar situation will also happen, that is FIQ INTID1023 is returned.

    Is my understanding right ?

    Thanks and regards. 

    Grace

Reply
  • 0 in reply to Martin Weidmann

     Hi Martin

    Per tests, I agree with you. 

    Besides, I have some other questions from tests.

    What I do is as follows:

    1. configure and enable a FIQ with priority 0 and an IRQ with priority 10.

    2. at the end of FIQ callback enable FIQ and IRQ (CPSR.I and F = 0)

    3. for some particular timing, before writing ICC_EOIR0, the IRQ asserts and the CPU goes to irq exception but the returned INTID is 1023.

    From the CPU interface registers: ICC_RPR is 0 that is the FIQ, and ICC_HPPIR1 is the IRQ ID. I think in this case, while entering irq exception, the CPU interface finds the HPPI IRQ has not sufficient priority as its priority 10 is lower than the active FIQ priority 0. So the special INTID 1023 (IRQ) is returned.

    And if FIQ has lower priority 10 and IRQ has higher priority 0, the similar situation will also happen, that is FIQ INTID1023 is returned.

    Is my understanding right ?

    Thanks and regards. 

    Grace

Children
No data