Handling for Interrupt

[tama]

Hello Sir,

I would like to ask about the handling of the interruption in the nRF52 SDK.

The versions for SDK and SoftDevice are 15.3.0 and S132 v6.1.1

In the processing of "nrfx_gpiote_irq_handler"(modules/nrfx/drivers/src/nrfx_gpiote.c), it seems that interrupts are not disabled during interrupt processing for one pin.
In this case, if one pin is interrupted multiple times in a short time, does the callback "gpiote_event_handler"(components/libraries/button/app_button.c) called from
 "nrfx_gpiote_irq_handler" work correctly?
After performing the first interrupt processing, is it waited for the next interrupt processing to be performed?

Best Regards,

Manabu Tajima

[Einar Thorsrud]

Hi,

In the processing of "nrfx_gpiote_irq_handler"(modules/nrfx/drivers/src/nrfx_gpiote.c), it seems that interrupts are not disabled during interrupt processing for one pin.

The interrupt is not disabled in the ISR, but that would usually not make sense either. However, it is cleared by a call to nrf_gpiote_event_clear().

In this case, if one pin is interrupted multiple times in a short time, does the callback "gpiote_event_handler"(components/libraries/button/app_button.c) called from
 "nrfx_gpiote_irq_handler" work correctly?

Yes. You can lose interrupts if multiple occur very fast (faster than it takes to process the interrupts). There is no way around this issue though, other than making sure that the code executed in the IRQ handler is as short as possible (including event handlers, etc. called from it with the same priority).

After performing the first interrupt processing, is it waited for the next interrupt processing to be performed?

Yes.

[tama]

Hello,

Thank you very much. I would like to ask about your answer.

>You can lose interrupts if multiple occur very fast (faster than it takes to process the interrupts).

>There is no way around >this issue though, other than making sure that the code executed

> in the IRQ handler is as short as possible (including >event handlers, etc. called from

> it with the same priority).

Is it right recognition that "gpiote_event_handler" in the "app_button.c" is enough short in the IRQ handler.

>After performing the first interrupt processing, is it waited for the next interrupt processing

>to be performed?

>Yes.

Does it mean that there is no interrupt processing in the multiplex and
the second interrupt processing will be in the pending state in the hardware?

Kind Regards,

Manabu Tajima

[Einar Thorsrud]

Hi,

tama said:

Is it right recognition that "gpiote_event_handler" in the "app_button.c" is enough short in the IRQ handler.

I am not entirely sure about the question, but yes. Unless you do something that takes a long time in the event handler, there should not be any problems. Particularly for button presses (which are extremely slow in this context).

tama said:

Does it mean that there is no interrupt processing in the multiplex and
the second interrupt processing will be in the pending state in the hardware?

If another interrupt occurs on a different IRQ number (of same or lower priority), that will be pending and will be serviced once the current interrupt is processed. But you cannot "queue" multiple interrupts for the same IRQ number. That is rarely a practical problem, though.