IRQHandler Detects Interrupt From Same Pin Number On Another Port But Only 1 Configured As Interrupt?

[Nic1]

Developing on an STM32F417ZG

I have configured PE2 as a rising edge interrupt. It is the only pin 2 set as an interrupt the others are configured as follows:

PA2: ETH_MDIO

PB2: Input pull-down

PC2: ADC1_IN12 (No analog watchdog)

PD2: Output

PF2: Input pull-down

PG2: Input pull-down

Sometimes the EXTI2_IRQHandler is called without a rising edge occurring on PE2. Verified by setting a break point at this function and probing PE2 with a scope. This happens randomly i.e. no set interval between occurrences and seemingly no triggers.

Is reading the GPIOE->IDR register in the interrupt callback function a reliable way to check if the interrupt came from port E? If not is there a reliable way to find on which port the interrupt occurred?

I am also having some difficulty tracing the code back from the EXTI2_IRQHandler, where is that function called?

[Tesla DeLorean]

>>I am also having some difficulty tracing the code back from the EXTI2_IRQHandler, where is that function called?

The NVIC causes the process to load/execute the IRQHandler via the vector table described in startup.s

[Nic1]

Okay I found that table in the startup.s thank you, is it possible to set a break point and see what port the trigger came from?

[Tesla DeLorean]

You can inspect the registers in the EXTI and GPIO peripheral. I don't think internal nets or logic tree are exposed in a way you can inspect them. Only one source is supposed to be gated.

[S.Ma]

Whenever using EXTI on a GPIO pin, make sure to confirm the source by looking at the PR bit then clearing it. It's not guaranteed that when the callback runs the pin level is the one expected as some time elapsed.

Also remember that sometime groups of pins share the same callback (EXTI10..15 means any pin from index 10 to 15 share the same interrupt vector.

[Nic1]

Thanks for pointing that out!

I've double checked and it looks like the HAL IRQHandler function is checking and clearing the PR register so at least it's verifying it is in fact a pin 2 causing the interrupt. But beyond the fact that only port e pin 2 is configured as an EXTI I don't seem to have any verification of the source port.

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);
 }
}

[waclawek.jan]

> Sometimes the EXTI2_IRQHandler is called without a rising edge occurring on PE2. Verified by setting a break point at this function and probing PE2 with a scope.

Make an inverse verification: connect PE2 to a hard level.

Is your scope (and probe/ground) fast enough to catch a few-nanosecond pulse?

JW

[waclawek.jan]

> Sometimes the EXTI2_IRQHandler is called without a rising edge occurring on PE2. Verified by setting a break point at this function and probing PE2 with a scope.

Make an inverse verification: connect PE2 to a hard level (ground or VDD). If there are no more interrupts, they did come from PE2.

Is your scope (and probe/ground) fast enough to catch a few-nanosecond pulse?

JW