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

[Karl Yamashita]

Did you enable the NVIC?

 

 

[robotwhisperer]

NVIC is enabled, so is the DMA Stream interrupt. The configuration is the same as my other question I posted here.
That is supposed to be an isolated subset of the main project, but somehow when I put the changes from that minimal example into the main project they do not work. 

 

[TDK]

Light on details here. Gotta be an issue somewhere. Wiring or code.

Here's an example of how to use HAL_UART_Receive_DMA that works:

STM32CubeH7/Projects/NUCLEO-H743ZI/Examples/UART/UART_TwoBoards_ComDMA/Src/main.c at fc00ae225a6bbc4f0838a45765c64bf8c4b20bee · STMicroelectronics/STM32CubeH7

[bmckenney]

Are you still using 1-byte transfers? (You mentioned something about sending ADC readings.)

The (Rx) DMA won't complete until it transfers the length you requested, so the other side has to send exactly that many.

A key setting in the example TDK mentioned:

> #define RXBUFFERSIZE TXBUFFERSIZE

[robotwhisperer]

Currently still using 1-byte transfers, yes. Once I get the UART Callback working correctly I will update the sizes to be the appropriate size (18 bytes for 9 16-bit ADC values in my case). 

My receiving side looks something like: 

 auto status = HAL_UART_Receive_DMA(huart3_, rx_buffer_.data(), 1);

And the sending side looks like:

 HAL_UART_Transmit_DMA(huart3_, data, 1);

Additionally, I did check the UART TX pin on the sender side with an oscilloscope and it does indeed send the byte as expected. 

[gbm]

Double-check the spelling of routine's name. Or - better yet - copy the name from the header file or HAL manual.

[robotwhisperer]

Thanks for the suggestion, I did copy the function name from the HAL file in the project, so I am sure it is not something like a typo somewhere. 

[TDK]

> but somehow when I put the changes from that minimal example into the main project they do not work. 

So probably an issue with the integration then. Perhaps an overrun.

Debug the program. When it "doesn't work", hit pause an examine the state of the huart handle and relevant UART/DMA registers.

[robotwhisperer]

Thanks for pointing that out. When I debug, I set a breakpoint on the HAL_UART_RxCpltCallback which is never hit. I added a live expression so that I can see the state of the uart handle while the project runs. Here is what I am seeing

I see that the error code is 0, which is good, since it means no error. However, the gState and RxState are non-zero, and I could not find a definition for them in the generated code. I think this might be important? 

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

 

[robotwhisperer]

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.