Cannot identify IRQ reason - STM32H753
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-16 5:33 PM
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
Solved! Go to Solution.
- Labels:
-
GPIO-EXTI
-
Interrupt
-
STM32H7 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-16 6:23 PM
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
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-16 6:23 PM
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
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-17 12:01 AM
There is no hazard or race, it would fall through harmlessly the second time, doing nothing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-17 12:19 AM
You and I will disagree, it loses the race, that's why it reenters. It is the classic definition of the failure case.​
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-17 12:39 AM
OK, there is a race, but no harm is done except a couple of wasted cycles.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-17 2:33 AM
More harm occurs if in apriori knowledge of only a single interrupt source you don't check it.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-17 3:57 AM
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
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-17 4:50 AM
> 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-17 5:46 AM
> Put __DSB() before return's to fence the write
Will try . thanks - pa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-01-17 3:38 PM
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
