cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot identify IRQ reason - STM32H753

Pavel A.
Evangelist III

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

1 ACCEPTED SOLUTION

Accepted Solutions

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

11 REPLIES 11

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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

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

JW

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

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

> 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

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

Will try . thanks - pa

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