• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 14 replies
  • Subscribers 349 subscribers
  • Views 10413 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

Very Urgent :VIC in ARM Cortex R4

Yash

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!

Parents
  • 0 in reply to Yash

    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

Reply
  • 0 in reply to Yash

    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

Children