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!
>if i have posted this question in wrong category
Don't worry, you've posted the question in the right place. :-)
The technical reference manual pf PL190 can be found in
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0181e/index.html
>Does VICIRQSTATUS register gives the currently IRQ interrupt servicing by processor.
No. VICIRQSTATUS give you the status of the interrupt requests after masking by VICINTENABLE and VICINTSELECT registers. This is separated from what the processor is serving. The diagram (figure 2.2) in this page should give you an idea what it means:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0181e/Cjachhef.html
> Which status gives the VICRAWINTR register
Again, fig 2.2 give you the idea. It is a combination of interrupt requests from peripherals and software interrupt requests.
> I want the current executing interrupt source number
There is no equivalent of IPSR as in Cortex-M. The PL190 and the Cortex-R4 are not as closely coupled together as NVIC in Cortex-M. So the only way to handle this is by software. The interrupt handling veneer could implement some code to create this IPSR in the memory. In the interrupt entry the interrupt veneer save the IRQ number of a pre-empted interrupt, and restore the old value when the interrupt handler ends.
regards,
Joseph
Dera Joesph,
Thank you very much for this kind and quick response.
I gone through your feedback You have nicely explained the things.I was already trying to get the interrupt source number to get the Interrupt source number by shifting the bit in IRQ STATUS register (but it is looking successes, when only one bit set at time while executing the interrupt corresponding bit interrupt source ) .
But it not happening as IRQSTATUS giving combination of interrupt requests from peripherals and software interrupt requests.
Could you please give me any idea to abstract the interrupt source or any reference .
2. Bit will remain Set in IRQSTATUS, until we will not disable the interrupt by VICINTENCLEAR Register?
Thanks !
The advantage of VIC PL190/PL192 is that in normal applications, you don't need to use source to determine which interrupt to service. The VIC allow you to setup the priority levels of the interrupts, and the exception vector of the highest priority interrupt will be visible in the VICADDRESS.
The read to VICADDRESS automatically update the VIC interrupt status and this set the interrupt masking level, so that same / lower priority interrupts are masked. And at the end of the ISR wrapper, you write the to VIC to let it know that the ISR is ending. This restore the interrupt masking logic so that the interrupt can be taken again if needed.
Please have a look at example code in PL190 TRM.
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0181e/Babcgdia.html
This code is quite old, in Cortex-R there are some extra instruction to accelerate interrupt handling at the core level. But the PL190 part is still the same.
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.
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.