• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 581 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/AM3358: Overlapping interrupts execution

qxc
Genius 5820 points
Part Number: AM3358


Tool/software: TI C/C++ Compiler

Hi,

assumed my application is running within the interrupt service routine of an interrupt (e.g. from Ethernet). What happens when an other event occurs, which causes an interrupt (e.g. a GPI is changed)? Is the GPI-intterrupt served as soon as I return from my Ethernet-ISR? Or is it dropped/ignored and I have to check on return somehow if an other interrupt is about to be handled? Has the interrupt-priority and influence on thie interrupt handling in this case?

Thanks!

  • 0
    TI__Guru**** 393215 points
    Hi,

    What software is this?
  • 0 in reply to Biser Gatchev-XID
    Genius 5820 points

    Plain bare metal based on the descriptions of the TRM.

  • 0
    TI__Guru** 116770 points
    QXC,

    The question is not AM335x specific but relates to ARM General Interrupt controller (GIC) configuration. The details regarding GIC is provided in the ARM TRM rather than the AM335x TRM so you are likely to find better answers to such question on ARM forums than on TI forums. For complex systems with multiple interrupts, we generally recommend use of an RTOS or a high level OS like Linux so end application user doesn`t need to deal with this GIC hook up and has OS level priorities that take care of such scenarios.

    By default, in most architecture, software turn off the global interrupt bit at the beginning of the ISR and then turn it back on at the end. So interrupts are disabled during the duration of the ISR. If you have an ISR where you also process some data then the ISR runs for a longer time creating possibility that you will miss a HW interrupt which is critical to real time systems. RTOS provides way to take that process data and move it out of the ISR, by putting the processing in a task thread or SWI (software interrupt) thread. This will shorten the length of our ISRs and ensure that system spends least possible time in interrupt disabled state. the scenario that you are describing is therefore not a typical scenario.

    However, I will try to answer this based on my understanding of the ARM GIC spec. The GIC supports minimum of 16 and a maximum of 256 priority levels. In the GIC prioritization scheme, lower numbers have higher priority, that is, the lower the assigned priority value the higher the priority of the interrupt. Priority field value 0 always indicates the highest possible interrupt priority. GIC also supports a grouping feature to support the handling of Secure(Group 0) and Non-secure (Group 1) interrupt they can be connected as IRQ or FIQ interrupt request. FIQs have higher priority compared to IRQs. Without getting into complete details let me point you to the full ARM GIC spec that is available here:
    infocenter.arm.com/.../index.jsp

    If you don`t have access then you can refer to the older version of the spec here:
    www.cl.cam.ac.uk/.../arm_gic_architecture_specification.pdf

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Genius 5820 points

    Rahul,

    thank you for your detailed answer. In my application the global interrupts are NOT turned off at the beginning of an ISR, so they are still allowed to appear.

    So assumed all of these interrupts have the same priority, what would happen with them - are they issued after the end of the current ISR or do they interrupt the ISR?

    Thank you!

    QXC

  • 0 in reply to qxc
    TI__Guru** 116770 points

    QXC,

    If interrupt of same priority occurs then it will be marked active and pending state so the current ISR will complete to execution and  it will ibe taken immediately after current ISR completes provided no other higher priority interrupt occurs in that time frame. 

    I would recommend that you refer to the responses on the ARM forum on this thread, the later threads refer to the GIC implementation on ARMv7 cores: 

    https://community.arm.com/processors/f/discussions/2875/what-happens-if-same-interrupt-comes-too-fast-in-an-arm-processor