STM32H7B3I - Receiving an unknown interrupt on the EXT9_5 after clearing the interrupts on all lines 5 - 9.

> clearAll_EXTI9_5_IRQ();

> HAL_NVIC_EnableIRQ(EXTI9_5_IRQn);

If there were pending interrupts in EXTI before you called clearAll_EXTI9_5_IRQ(), there may be an interrupt thrown immediately after the enable. Reason is, that it takes time until changes in EXTI pending register propagate to NVIC.

Unfortunately, there is probably no universally good solution. I tried to tackle this on an 'F4, clearing first the interrupt source (here EXTI, I experimented with TIM, but there is no difference in this regard) then interrupt pending in NVIC, but I found out that due to the undocumented internal timing if I did this quickly enough, the interrupt in EXTI "reappeared" after a few cycles. You may need to perform a similar experiment for your 'H7 (which is inifinitely more complex than 'F4) and ascertain, what influences might make one particular such assesment void (e.g. changing APB divider).

JW

Check the pin level in the interrupt, disable the interrupt once happening, and use a timer delayed interrupt to reenable them after some programmable ignore time. Maybe the EXTI needs optional filtering like timer input captures.....

Hi,

I put an operating system vTaskDelay between the clearing and enabling AND a CPU time delay loop and I still get an interrupt that doesn't match the input pins 5 to 9.

HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_5);
	clearAll_EXTI9_5_IRQ();
	vTaskDelay(2);
 timeDelay_usec(100);
 HAL_NVIC_EnableIRQ(EXTI9_5_IRQn);

Still got the unidentifiable interrupt! 

I did think about a timer using a digital filter, but I've run out of timers for this project. But in any event the interrupt that is occurring doesn't match any of the external interrupt pins I'm using; the data ready from the WiFi module and the SD Card switch. Which one of the two would I put the timer on?

What is generating this interrupt; it's not one of my two pins.

I would like an answer from ST, they designed the chip surely they should be able to advise.

If there is a problem with the silicon then fess up, at least I would know what I'm facing.

In fact given the size of the interrupt space for the H7 why not have a separate interrupt for each of the 16 external interrupt pins? This business of having to work out "which pin was that" is an unnecessary delay in processing interrupts.

It's ridiculous!

Best regards

Rob

Test by clearing the PR bit at the very end of tge interrupt.

Outside the ISR, you have to clear also the NVIC pending bit, as I did in the post linked above.

> I would like an answer from ST,

Then ask them. This is a primarily user-driven forum, with casual ST presence.

> why not have a separate interrupt for each of the 16 external interrupt pins?

I'm sure ST will gladly produce an mcu as per your specifications, given enough incentives (expressed usually in M$s). Otherwise, it's a tradeoff between capabilities and silicon real estate (= unit cost).

JW

@Garnett.Robert (Community Member)

As Jan and others wrote, H7 is complicated. There can be delayed/buffered writes that require explicit flush (DSB) and even this not always is enough, requires a read-back or even worse.

IMHO your experiment with added delays is not 100% convincing.

To avoid wasting time IMHO you only need to check that unknown cases in shared EXTI hander go away in "short" time : there are no more than N handler calls in a row, before a good handler call.

Your diligence is a good thing but here you're chasing a known chupacabra.

> I assumed that the code in the HAL GPIO External interrupt handler was sufficient to clear ALL of the necessary register bits

It is, but only if you are executing the ISR. But from non-interrupt context, you have to explicitly clear also the NVIC pending bit (see NVIC_ICPRx register). This is what I quoted above: if the interrupt kicks in, it clears this bit in hardware; but if it's not the interrupt context, you have to do it yourself.

So the procedure is:

• clear the interrupt source (by writing to EXTI pending register)
• wait - this is the tricky part
• clear the NVIC pending bit (by writing to NVIC_ICPRx, for which CMSIS provides the NVIC_ClearPendingIRQ() function)
• here wait shouldn't be necessary, but I am not entirely sure
• enable the interrupt in NVIC

JW

Hi PA,

Yes it's definitely a timing problem. If you single step through the IRQ Handler it does not produce a second interrupt.

To fix the problem you basically just need a few instructions immediately prior to the return in the IRQ Handler.

I tried a few different ones just too experiment, obviously only one at a time:

void EXTI9_5_IRQHandler(void)
{...
 
 k = 1; /* or */
 __DSB(); /* or */
 
 register int k; 
 for (k = 0; k < 1; k++){} /* or */
 
 NVIC_ClearPendingIRQ(EXTI9_5_IRQn);
 
 asm("nop"); /* No amount of these in-lined fix the problem I tried 10 */
 
 
 return;
}

With the exception of the simple nop's all of these variation fixed the problem.

So I think that the __DSB(); is probably the best of these. I am not sure whether the function of this memory barrier instruction plays a part or whether it is simply timing. If you wanted to clear all of the line interrupts for some reason then clear pending would be OK, but I'm not sure, but it could cause a loss of interrupts that occur whilst the interrupt handler is executing.

The execution times for the various methods is very small, but the dsb is the fastest:

Anyhow I will use DSB as it works, is the fastest and shouldn't be optimised out by the compiler.

• DSB 265ns
• Loop 301 ns
• Clear Pending 414 ns

Something weird happened with my last upload so I've posted it uncleaned below

Regards

Rob

Read the ARM Application Note 321 section "4.9 Disabling interrupts at peripherals".