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.
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 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.
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.