Hi all,
It was nice experience working with NXP with my favorite S32K1XX series having ARM Cotex M-4 and M-0+.
Now i switched to BCM895XX series with ARM Cotex R-4 having VIC for interrupt contolling.
I am working with controller having ARM cortex R-4 , which supports VIC (PL190) for interrupt controlling. I searched a lot but not satisfied. Now i come here again.
I have few questions:
1- Does VICIRQSTATUS register gives the currently IRQ interrupt servicing by processor.
2. Which status gives the VICRAWINTR register.
3. I want the current executing interrupt source number( decimal number out of 32 interrupt source ) at run time . I am only getting the status bit being set in STATUS register . Also I am not getting any register supported by Cortex R-4 to get the interrupt source number. How I can get this number .
Please help me on this and also let me know if i have posted this question in wrong category.
Thanks!
Hi Joseph ,
I have gone through the code of PL190 TRM. There is "Read from VICIRQStatus to determine the source of the interrupt" .
1. How i will get the interrupt source number from VICIRQStatus ?
2. When bit of VICIRQStatus get clear ? it would only clear when i disable the interrupt by setting the bit in VICIRQStatus ?
3. Is there any register(or bit of register) of VIC ,which must be used to clear in IRQ subroutine ?
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 ?
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.
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.