Cannot identify IRQ reason - STM32H753

[Pavel A.]

I have the following EXTI9_5 handler: (yes, with HAL)

void EXTI9_5_IRQHandler(void)
{
 if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_6) != 0)
 {
 __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_6);
 return;
 }
 
 if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_5) != 0)
 {
 __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_5);
 return;
 }
 if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_7) != 0)
 {
 __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_7);
 return;
 }
 if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_8) != 0)
 {
 __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_8);
 return;
 }
 if (__HAL_GPIO_EXTI_GET_IT(GPIO_PIN_9) != 0)
 {
 __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_9);
 return;
 }
 __BKPT(6); // unknown reason
 __NOP();
 __NOP();
}

After enabling EXTI9_5, it permanently hits the __BKPT(6) line.,

This means, all checks for pins 5,6,7,8,9 fail and the reason of the interrupt is not identified.

How this is possible? Can EXTI9_5 interrupt occur for other reasons besides of pins 5,6,7,8,9?

Puzzled...

-- pa

[Tesla DeLorean]

You could dump registers.

Probably the pipeline/write-buffer problem, common in M3/M4 for TIM, ie can't clear the source before you leave and processor/NVIC still flagging, and then tail-chains with nothing pending. Basically a hazard/race-condition.

Put __DSB() before return's to fence the write

[berendi]

There is no hazard or race, it would fall through harmlessly the second time, doing nothing.

[Tesla DeLorean]

You and I will disagree, it loses the race, that's why it reenters. It is the classic definition of the failure case.​

[waclawek.jan]

More harm occurs if in apriori knowledge of only a single interrupt source you don't check it.

JW

[Pavel A.]

> More harm occurs if in apriori knowledge of only a single interrupt source you don't check it.

Jan pardon me I don't understand your note. The handler above checks all possible sources, but appears that something is missing.

Dumped the EXTI registers (actually used the register viewer of Atollic).

CPUPR1.PR6 is set, so it looks like interrupt from pin6 (which is actually expected).

The __HAL_GPIO_EXTI_GET_IT(GPIO_PIN_6) macro indeed reads CPUPR1.PR6, but that path in the code is not taken. Mistery...

-- pa

[waclawek.jan]

That was a reply to berendi's "no harm" remark, but regarding interrupt handlers generally, not specifically your particular case (to which it indeed does not apply) , sorry for the confusion.

Jan

[Piranha]

Highly recommended:

https://community.arm.com/developer/ip-products/processors/f/cortex-m-forum/10389/dmb-dsb-isb-on-cortex-m3-m4-m7-single-core-parts

http://infocenter.arm.com/help/topic/com.arm.doc.dai0321a/BIHJHJJA.html