I’m working on a custom board including a STM32H723.
From a FPGA I have a simple signal that pulses for a few 1us at roughly 50kHz.
This goes to an IO pin.
I’ve hooked up an interrupt EXTI15_10_IRQHandler to trigger on the rising edge.
Inside this routine I increment a volatile variable and toggles an IO pin too.
I clear the pending bit in the EXTI-PR1 register too.
#pragma GCC push_options
#pragma GCC optimize ("O2")
volatile unsigned int intspersec = 0;
void EXTI15_10_IRQHandler(void)
{
SCOPE_DEBUG_0; // Toggles external IO pin
intspersec++; // Count em
// NVIC_ClearPendingIRQ(EXTI15_10_IRQn); // Does not help
if (LL_EXTI_IsActiveFlag_0_31(LL_EXTI_LINE_14)) {
LL_EXTI_ClearFlag_0_31(LL_EXTI_LINE_14);
} // endif
// Lets waste some time
for (volatile unsigned int n=0;n<1;n++) {
} // endfor
return;
}
#pragma GCC pop_options
The interrupt is set to falling edge and I’ve verified that changing it to rising edge makes the expected difference in the timing.
The problem is that the above interrupt handler is executed twice – see scope shot.
Double invocation
The top trace is the debug IO pin, while the lower (analog) is the input PE14 pin.
The absolute weird part is that if I waste a little more time in the ISR like this
// Lets waste some time
for (volatile unsigned int n=0;n<2;n++) {
} // endfor
I get a single invocation of the ISR as expected…
I’ve tried running the code with or without ICache/DCache etc. but it does not seem to make any consistent differences.
We’ve done many many designs with the STM32 family (F1,F4,G0,L0,L1..) but this is the first H7 design.
Of course we can work around this issue, but I would prefer understanding why it happens, so that it does not end up biting me, in some other form, later.
JacobSkjoet is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.