UART IRQ fired but no IRQ source configured

[regjoe]

Hello,

I have a H7 design with multiple UART/USART used to communicate via RS485 drivers (XR3072).

I have programmed kind of loopback test by connecting the A/B signals of two RS485 busses.

For this I use 2 DMA channels for each UART, one for RX and one for TX.

Test runs fine, but if I connect a probe to RX signal, I get an UART IRQ with frame error flag set.

I found out that the RX output of the RS485 driver is tri-state during transmit, so this the source of the frame error. It can be solved using external or internal pull-up resistors. This is not the problem, just FYI.

What puzzles me:

First, I have no clue why this IRQ is fired at all. In my understanding, in order to fire an UART IRQ, the appropriate enable bits must be configured in CR1-3. In this case, only in CR1 the RE, TE and UE are set.

Here is the content of CR1 and IRQ registers when the UART IRQ handler is fired:

Second, to my surprise, the HAL IRQ handler simply does nothing, no error is thrown or error callback is run. Seems to me that the frame error is only processed during receive. If no transmission is active, the frame error is ignored.

Any idea what caused the IRQ to be executed?

Thanks,

Jochen

[Pavel A.]

> Second, to my surprise, the HAL IRQ handler simply does nothing

What happens if you just let it return? Will the handler run again in a loop?

[regjoe]

No, it is only fired once. It can be ignored. I just want to understand why it is fired.

Maybe this is a leak/bug in the HAL UART IRQ handler?

[Guenael Cadier]

Hi @regjoe ,

what is the content of your CR3 register ? (an USART IRQ will be raised on FE flag raising, only if EIE bit is set in CR3). If not, the IRQ source might be not related to FE flag ...

[regjoe]

Hi @Guenael Cadier ,

CR3 is 0, FE IRQ is not enabled. Here is what the debugger watch window looks like when the IRQ handler is entered and the local variables (isrflags, errorflags, ...) are read:

[Guenael Cadier]

As there's no interrupt source enabled in CR1 nor CR3, I have no explanation why IRQ Handler is called. I guess you already checked thet UART IRQ Handler call is properly associated to the right IRQn ...

[regjoe]

Good question. How can I check that the link is correct? I simply trust CubeMx that the generated code is OK. At least, it seems that the appropriate IRQ handlers are involved when I step thru the code.

I think that the cause is a short spike on RX when the transfer direction is switched on the RS485 bus drivers and at the same time the TX and RX DMAs are initialized using HAL.

During DMA init the EIE bit of the UART is enabled for the RX UART and disabled for the TX UART. Seems this causes a race condition.

Is it possible that the frame error is detected and stored while EIE is disabled? And the IRQ is fired as soon as the EIE is enabled?

[Pavel A. · Accepted solution]

Only fired once => this  can be a delay in propagation of interrupt clear signal to the core NVIC.

Please see here: http://efton.sk/STM32/gotcha/g7.html  

(thanks Jan W.) 

> Is it possible that the frame error is detected and stored while EIE is disabled? And the IRQ is fired as soon as the EIE is enabled?

IMHO possible. This is why in a real life project these interrupts should not be repeatedly enabled and disabled, and receive usually should run continuously, with error handling & recovery.

[Guenael Cadier]

@regjoe 

"Is it possible that the frame error is detected and stored while EIE is disabled? And the IRQ is fired as soon as the EIE is enabled?"

Yes if a Frame error is detected FE will go 1 independently from EIE value. And once EIE is set to 1 an interrupt is fired. In normal case, when entering IRQ handler, we should be able to see EIE still at 1 in CR3.

But, for very specific timings, explanation from @Pavel A. seems right.
Thanks.

[regjoe]

Frankly, I do not understand what exactly happens in my test scenario, but it seems to me it is quite complicated to track down what happens inside this chip.

For me, it is important to know that IRQ can appear at any time which are not necessarily related to enabled sources. So the current implementation of the HAL UART handler, which simply ignores these IRQs, seems correct.

Thank you very much for your answers.