HAL_UART_RxCpltCallback never triggers

[robotwhisperer]

I am implementing a system with two STM32H753 microcontrollers. MCU1 reads ADC data and sends it over UART to MCU2 using UART DMA on ADC conversion. MCU2 reads data from UART via DMA and is supposed to do some filtering (among other things) to the received data. Earlier, all of the tasks were done by a single MCU (hence it was simpler, as we had access to the ADC data buffer already). 

The issue I am facing is that the UART Receive DMA is never triggering the HAL_UART_RxCpltCallback() callback no matter what I do. I have tried the same with UART_Receive_IT() with no results either. 

To help me ensure that it is not a configuration issue, I configured the same UART in a separate project (which is more of a simpler example of what I am trying to do) and verified my configuration to be working (posted about it earlier). 

[robotwhisperer]

It looks like RxState = 0x22 means HAL_UART_STATE_BUSY_RX, which means that the UART is waiting to receive constantly, which might be why it is never hitting the callback function. Why could this be? Both boards are only connected with less than 6 inches of jumper (breadboard) wires like this:

MCU1:                                MCU2:
GND ----------------------------GND
TX---------------------------------RX

[Pavel A.]

> RxState = 0x22 means HAL_UART_STATE_BUSY_RX

Unsupported combination of simultaneous RX and TX functions, or calling RX DMA function while the previous call hasn't completed.

[bmckenney]

It seems odd that if you called Receive_DMA(), CR3:DMAR (0x40) is not set but CR1:RXNEIE (0x20) is set. Are you requesting RXNEIE? I've always been superstitious about setting both RXNEIE (RXNE triggers NVIC interrupt) and DMAR (RXNE triggers DMA request) since the RM doesn't say what happens in that case; I wonder whether the HAL does something odd with this combination.

Test case: In which order are you starting the two sides? Does the Tx side try sending more than once?

More generally: This seemed to (mostly) work last week. What has changed in the meantime?

[robotwhisperer · Accepted solution]

Thanks everyone for the help. It was a buffer size mismatch issue. I figured it out shortly after my last post on here. I just followed some of the "How to Debug" guides posted on one thread on here, and one of them was to "Check your assumptions" and when I did I found the problem.

The receive buffer was thousands of times larger than I thought, so it would take a long time for it to fill up and trigger. When I posted about this the last time, I was working with a basic example, but when I integrated it into a larger project, it did not work because the UART buffers were initialized and managed in another file and all the constants (such as the buffer size) were in a different file too. 

Good reminder for me to check and double check assumptions. Thanks again, everyone.