Need some help to understand why pending interrupts are no longer serviced.

[Softronic Solutions]

Need some help understanding an interrupt lockup situation.

Written some code that is highly depending on interrupts getting serviced. It works fine as long as there is no interrupt nesting situation.

In more detail I'm using printf calls/trace messages all over my code to get insight in code execution. The printf calls get handled by the USART which on its turn uses a DMA channel to send the actual message thru the TX pin. In order to signal end of transmission the DMA channel fires an interrupt event to the USART driver that signals end of transmission.

Below snapshot concerns a debug screen were my application code has entered a while loop basically awaiting the end of transmission from the USART/DMA. The actual DMA interrupt is pending but never get's executed.

 

So my question is what can be at the root cause for interrupts not getting serviced?

Is this a question of altering interrupt priority?

[Softronic Solutions]

[Bob S]

You are calling printf/puts from your interrupt routines??????? It looks like the interrupt interrupted an existing printf/puts sequence so it likely either corrupted it, or, since the newer interrupt has a higher priority than the UART interrupt, it blocks the UART interrupt from ever happening, so the "done" flag never gets set.

[Tesla DeLorean]

Priority Inversion, and blocking/deadlocking on things that can't clear in the current execution path.

Avoid any blocking code, or non-buffered output, during interrupts and callbacks.

If an interrupt remains pending, or re-pends, the tail-chaining will cause it to re-enter, often repeatedly. Other interrupts with lesser priority will be blocked, there isn't a round-robin service methodology, it's mostly dependent on priority and time of arrival.

Watch also preemption levels.

ST's HAL code frequently has code dependent on SysTick preempting, and timeout/delays expecting the HAL Tick to advance.

[Softronic Solutions]

Hey Bob,

In fact I did store the printf output first in a linked list buffer, but needed to trigger the transmission somehow and this was also also done in the write_ function > my bad. Created a new task responsible for reading the buffer and handling the UART and that solved the issue.

Anyway it was not the printf itself that caused the issue. However I understand your concern printf if slow therefore it's only compiled in using a DEBUG compiler switch.

[Softronic Solutions]

Thanks that helped a lot. See above reply to Bob for more info.