Very Urgent :VIC in ARM Cortex R4

Hi Yash,

Please read section 2.2 of PL190 Technical Reference Manual which show expect usages

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0181e/I1006538.html

You can either use Vectored interrupt flow (utilized VICADDRESS to determine interrupt vector), or simple interrupt flow (use software to determine interrupt vector).

I see that you ask about that in

https://community.arm.com/processors/f/discussions/9701/bit-scan-instruction-arm-cortex-r4

Using RBIT and CLZ enable to get the IRQ number for the lowest number pending IRQ. But as you noticed, there can be cases where two IRQs can be asserted at the same time. How you define the priority in that case is up to you in software implementation.

In simple design, I would expect the default handler will:

- read VICIRQstatus

- masked out vectored interrupts (as they should be handled by vectored interrupt handlers, not default interrupt handler)

- use simple branch tress (highest priority IRQ is checked first, then second priority, ...) to decide what to do.

The VICIRQstatus is clear if:

- the peripheral deasserted the interrupt, or

- the interrupt is disabled at PL190.

Normally your IRQ handler need to clear the interrupt request at the peripheral. Please note there could be a delay from clearing of the interrupt request to the stage that the VICIRQstatus actually get updated (a few clock cycle delay). This is depending on the chip design.

regards,

Joseph

Hi Yash,

Please read section 2.2 of PL190 Technical Reference Manual which show expect usages

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0181e/I1006538.html

You can either use Vectored interrupt flow (utilized VICADDRESS to determine interrupt vector), or simple interrupt flow (use software to determine interrupt vector).

I see that you ask about that in

https://community.arm.com/processors/f/discussions/9701/bit-scan-instruction-arm-cortex-r4

Using RBIT and CLZ enable to get the IRQ number for the lowest number pending IRQ. But as you noticed, there can be cases where two IRQs can be asserted at the same time. How you define the priority in that case is up to you in software implementation.

In simple design, I would expect the default handler will:

- read VICIRQstatus

- masked out vectored interrupts (as they should be handled by vectored interrupt handlers, not default interrupt handler)

- use simple branch tress (highest priority IRQ is checked first, then second priority, ...) to decide what to do.

The VICIRQstatus is clear if:

- the peripheral deasserted the interrupt, or

- the interrupt is disabled at PL190.

Normally your IRQ handler need to clear the interrupt request at the peripheral. Please note there could be a delay from clearing of the interrupt request to the stage that the VICIRQstatus actually get updated (a few clock cycle delay). This is depending on the chip design.

regards,

Joseph

Hi Joseph,

I know that you may have some busy schedule , i am sorry for for interrupting you again.

In above image i am expecting Idly, that each time in STAGE5 should reach and led should toggle .

But it is not happening in real scenario, when i am giving free go in my debugger.

Why it is interrupting again even i did not clear the flag yet ? as it is not reaching to STAGE5, where i am clearing the Timer0 interrut over flow flag.

Is there any role of interrupt latency ?

Thanks!

Which interrupt handling flow are you using? (Vectored Interrupt flow provided by PL190, or the simple flow? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0181e/I1006538.html 

From what you said, you might be using simple flow, and with this flow you should not be reenabling interrupt in stage 4. Because when you do that, the processor can accept another interrupt request immediately.

If you want to use nested interrupt support, you should be using Vectored Interrupt flow. When VICADDRESS is read, then the internal masking logic is update and block the interrupts that are same or lower priority. After that, you can execute CPSIE I and that allows new interrupt request that has higher priority than the current one to be executed.

As an experiment, you can add a line of code in stage 4 (a few cycles before CPSIE I) to read VICADDRESS to force the VIC to update the priority level setting. Stage 5 should be called by OS_ISR (rather than branch), and after stage 5 is executed, execute CPSID I, and then write to VICADDRESS to restore the PL190 state.

I am travelling in Asia for 2.5 weeks from tomorrow and then in Embedded World in Germany so won't be able to check this thread regularly next few weeks.

regards,

Joseph

Hi Joseph，

Sorry for raise this old topic again. But I met issues on our SOC and need your help. 

Per this line in your reply " This restore the interrupt masking logic so that the interrupt can be taken again if needed." 

May I know the interrupt masking logic will be restored to lowest or just the one below the ISR it just served?

In general "restore" means, back to the former state.

42Bastian Schick is right. From memory PL190 is a hardware "stack" so that when writing to VICADDRESS, the priority level value is back to the value where it was (before the servicing interrupt occurred).

Joseph Yiu 42Bastian Schick Many thanks for the quick reply. It is clear to me now.

Joseph Yiu  Actually, I am using PL192. Suppose the behavior here is same with PL190? 

Yes, PL192 also has a hardware stack for the priority level.