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 · Accepted solution]

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.​

[berendi]

OK, there is a race, but no harm is done except a couple of wasted cycles.

[waclawek.jan]

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

JW

[Tesla DeLorean]

I tend to presuppose people in this field have some Computer Science or Computer Architecture background, I'm an Electronics Engineer who did IC design and had computers figured out in high-school (secondary)

These are all "things"

https://en.wikipedia.org/wiki/Hazard_(computer_architecture)

https://en.wikipedia.org/wiki/Memory_barrier

https://en.wikipedia.org/wiki/Race_condition

The ARM philosophy was to remove unnecessary transistors, understand the underlying hazards, and code with an understanding of them. Intel's was to throw a billion transistors at a problem, and erect safety fences around every cliff, divot and pit-trap. You'd have to try really hard to take a selfie and fall over.

#TrippingOnFlatSurfaces

[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

[Pavel A.]

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

Will try . thanks - 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