cancel
Showing results for 
Search instead for 
Did you mean: 

UART IRQ fired but no IRQ source configured

regjoe
Senior

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:

uart_irq_status.png

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

 

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

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.

 

View solution in original post

9 REPLIES 9
Pavel A.
Super User

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?

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
ST Employee

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 ...

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:

 

uart_irq_regs.png

Guenael Cadier
ST Employee

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 ...

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?

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
ST Employee

@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.

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.