Can a large number of different interrupts of the same priority on the STM32F4 cause problems?

[devchang]

I am experiencing processor freezes at certain points of use in our products using STM32F4.
I am analyzing the cause and have a question regarding this.

The processor I am using is STM32F469NI.

There is a specific operation that it freezes at, and when it does, it intermittently, but not always, goes into a state where it can't process other operations at all.
The main characteristic of this behavior is the frequent occurrence of different interrupts with exactly the same priority down to subpriority.
One interrupt is the EXTI3 IRQ, and it's almost periodic at about 30 Hz. The other is the USART1 IRQ, which occurs when data is received at baud rate 115200 at the time of the problem.

These two kinds of interrupts are identical, with a priority of 5 and a subpriority of 0. I wonder if the accumulation of pending interrupts that can't be handled at the moment is causing the processor to go into an abnormal interrupt handling state. Could this actually be causing the processor to get into trouble?

The reason I suspect this is that when using STM32 processors, I have often seen that if I set a breakpoint using ST Link in the middle of a large number of USART interrupts, stop the program and run it again, the accumulated USART interrupts that were not handled during the stop will cause the problem, and the USART interrupts will seemingly repeat indefinitely even though no data is being received.

If there are any other possible causes besides the ones I suspect, I'd be grateful to know, and it would also be nice to know under what circumstances the infinite interrupts symptom I suspect might occur.

Thank you.

[waclawek.jan · Accepted solution]

> I wonder if the accumulation of pending interrupts that can't be handled at the moment is causing the processor to go into an abnormal interrupt handling state.

Certainly not.

Most likely the problem is in your program.

There is no such thing as "processor freeze"; it always "does something", e.g. executes an infinite loop in the hardfault handler. Or, in your case, probably executes the same interrupt over and over, due to interrupt source not being cleared properly in the ISR.

> the accumulated USART interrupts that were not handled during the stop will cause the problem, and the USART interrupts will seemingly repeat indefinitely even though no data is being received.

My guess is that you don't handle the USART Overrun Error, or don't handle it correctly.

JW

[devchang]

Thank you, that was very helpful.
Actually, the ORE was not being cleared when the USART interrupt occurred, so I think it was going around the interrupt loop infinitely.

So I guess at a time when EXTIs with the same priority occur frequently, there is a high probability of getting at least one USART overrun error and thus a high probability of getting stuck in an interrupt infinite loop, do you agree with my guess?

[Tesla DeLorean]

Why guess?

Perhaps reevaluate preemption and priority. 

Reduce time and processing in interrupts.

Consider using DMA ring buffers to increase your margins.