2019-12-10 11:40 PM
I have configured 5 interrupts on EXTI line.....It works fine when I operate one at a time but misses out one interrupt when operated simultaneously.....Following is my GPIO configuration:-
void MX_GPIO_Init(void)
{
GPIO_InitTypeDef GPIO_InitStruct;
/* GPIO Ports Clock Enable */
__HAL_RCC_GPIOC_CLK_ENABLE();
__HAL_RCC_GPIOD_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();
__HAL_RCC_GPIOB_CLK_ENABLE();
/*Configure Input GPIO pins */
GPIO_InitStruct.Pin = GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2;
GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING_FALLING;
GPIO_InitStruct.Pull = GPIO_PULLUP;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_3|GPIO_PIN_4;
GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING_FALLING;
GPIO_InitStruct.Pull = GPIO_PULLUP;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
/* EXTI interrupt init*/
HAL_NVIC_SetPriority(EXTI0_IRQn, 0, 1);
HAL_NVIC_EnableIRQ(EXTI0_IRQn);
HAL_NVIC_SetPriority(EXTI1_IRQn, 0, 2);
HAL_NVIC_EnableIRQ(EXTI1_IRQn);
HAL_NVIC_SetPriority(EXTI2_IRQn, 0, 3);
HAL_NVIC_EnableIRQ(EXTI2_IRQn);
HAL_NVIC_SetPriority(EXTI3_IRQn, 0, 4);
HAL_NVIC_EnableIRQ(EXTI3_IRQn);
HAL_NVIC_SetPriority(EXTI4_IRQn, 0, 5);
HAL_NVIC_EnableIRQ(EXTI4_IRQn);
}
Have I configured the priorities incorrectly???
Solved! Go to Solution.
2019-12-11 12:59 AM
You did not tell us which STM32.
> It works fine when I operate one at a time but misses out one interrupt when operated simultaneously.
Cube/HAL is open source. Check, how it handles the rising/falling interrupts. As there's only one interrupt latch per line, there's only one interrupt per line, so if both rising and falling edge occurs on the same line while other interrupt of same or higher priority is handled, you will get only one interrupt. And, if there are more rising or more falling edges than one within that timeframe, you're going to lose them, resulting in only one edge being detected.
Getting rid of Cube/HAL may help in reducing latencies, but don't expect miracles. Measure your latencies (e.g. by toggling an output pin and observing it on a oscilloscope/LA) and compare to the desired input signal's timing.
If your input signals are too fast and you want e.g. to count, them, you should consider a different way to detect them, eg. tying them to a timer input line and use external counter mode of timer.
JW
2019-12-11 12:59 AM
You did not tell us which STM32.
> It works fine when I operate one at a time but misses out one interrupt when operated simultaneously.
Cube/HAL is open source. Check, how it handles the rising/falling interrupts. As there's only one interrupt latch per line, there's only one interrupt per line, so if both rising and falling edge occurs on the same line while other interrupt of same or higher priority is handled, you will get only one interrupt. And, if there are more rising or more falling edges than one within that timeframe, you're going to lose them, resulting in only one edge being detected.
Getting rid of Cube/HAL may help in reducing latencies, but don't expect miracles. Measure your latencies (e.g. by toggling an output pin and observing it on a oscilloscope/LA) and compare to the desired input signal's timing.
If your input signals are too fast and you want e.g. to count, them, you should consider a different way to detect them, eg. tying them to a timer input line and use external counter mode of timer.
JW
2019-12-11 02:45 AM
What are the IRQ Handlers doing?
Could they be clearing the wrong source?
Wouldn't have them preempt this way. Check you have stack depth to accommodate whatever your callbacks are up to.
2019-12-15 09:15 PM
The problem was of pending interrupt flag. It was not clearing the Pending IRQ. Solved the issue. :)