Relationship between GPIO Interrupt and SPI Communication

[pass3master]

We are trying to do SPI communication in the GPIO interrupt handler.
We are not sure about the following two points. Can someone please give me an answer?

1, If another GPIO interrupt occurs while the GPIO interrupt handler is running (with the same priority), does it wait for the GPIO interrupt handler running first to complete before running the later GPIO interrupt handler?
Or is the later GPIO interrupt ignored?

2,We would like to disable GPIO interrupts during SPI communication in order to perform SPI communication in the GPIO interrupt handler.
How should we write the program?

[Andrew Neil]

Generally, doing any operation which takes a significant amount of time in an interrupt handler is a Bad Idea.

Why do you feel the need to do this?

[pass3master]

Oh, I see.

We are doing SPI communication (100μs) in the GPIO interrupt handler, but there is a possibility that the next GPIO interrupt comes in during SPI communication.

We are doing SPI communication in the GPIO interrupt handler.”
↑Is this idea wrong?

[SofLit]

The EXTI pending bit is cleared as soon as the interrupt handler is executed:

void HAL_GPIO_EXTI_IRQHandler(uint16_t GPIO_Pin)
{
  /* EXTI line interrupt detected */
  if(__HAL_GPIO_EXTI_GET_IT(GPIO_Pin) != RESET)
  {
    __HAL_GPIO_EXTI_CLEAR_IT(GPIO_Pin);
    HAL_GPIO_EXTI_Callback(GPIO_Pin);
  }
}

Then the callback is called. So if in meantime (execution of the callback) an EXTI interrupt is fired, as soon as you exit the handler you will enter it again.

[Andrew Neil]

---

@pass3master wrote:

Is this idea wrong?

---

As I said, it's generally not a good approach.

Not enough detail to say whether you might just get away with it in your particular case.

Again, why do you feel the need to do the SPI comms within the interrupt handler?

[pass3master]

Thank you for your answer.
I see. So when a GPIO interrupt occurs within an interrupt handler, it is put on hold and the handler is executed again immediately after it finishes.
Thank you. That's very helpful.
Is there a way to prevent GPIO interrupts from occurring within an interrupt handler?

[pass3master]

Five switches are connected to a CPU (microcontroller), and FPGA.
Our customer requests that SPI communication be performed between the CPU (microcontroller) and FPGA when a switch is pressed.
Each of the five switches performs different SPI communication, and the moment a switch is pressed, there is a possibility that the other switches will also be pressed.
For this reason, we are planning to detect switch changes via GPIO interrupts and perform SPI communication.

[SofLit · Accepted solution]

---

@pass3master wrote:

Is there a way to prevent GPIO interrupts from occurring within an interrupt handler?

---

The interrupt does not occur within the interrupt handler. If it's the same IRQ handler it waits for the interrupt routine to finish and get back to it again. If another EXTI with higher preemption priority it will stop the execution of the lowest priority interrupt and execute the highest one.

[Andrew Neil]

So a common approach would be to just set a flag (or flags) in the switch interrupt handler(s), and then your mainline code checks the flag(s) for when to send the SPI message(s).

You have debounced these switches - haven't you ... ?

[pass3master]

I see, that's how it works.
Thanks to you I understand it now.
Thank you.