Skip to main content
Associate II
February 13, 2026
Question

An exception occurred after using HAL_UART_Transmit_DMA with HAL_UART_AbortReceive.

  • February 13, 2026
  • 2 replies
  • 246 views

Chip model: STM32H723VGTx
Both the RX and TX buffers are allocated in the D2 domain.

1.CubMx settings are correct.
2.HAL_UART_Transmit_DMA runs normally on the first run.

However, after running HAL_UART_AbortReceive, HAL_UART_Transmit_DMA fails.

Tracing the HAL_UART_Transmit_DMA function:
The huart->gState value is always 0x33.

2 replies

Technical Moderator
February 13, 2026

Hello @YutinhLin 

Why you are calling HAL_UART_AbortReceive() after a transmit operation?

If your intention is to abort an ongoing transmission, you should use HAL_UART_AbortTransmit() instead.

 

 

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Saket_Om"
YutinhLinAuthor
Associate II
February 13, 2026

I use `INFO.RX.count=CO_UART_BUF_LENGTH-(__HAL_DMA_GET_COUNTER(CO_INFO.channel->hdmarx));` to calculate the data index,
and I need to reset the index to 0 each time.

So I tried using `HAL_UART_AbortTransmit()`, but it didn't work.
Then I tried using `HAL_UART_AbortReceive()`, and it worked.

Technical Moderator
February 13, 2026

Hello @YutinhLin 

You should investigate why HAL_UART_AbortTransmit() is not working. 

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Saket_Om"
TDK
Super User
February 16, 2026

Duplicate:

STM32H723VGTx DMA TX reboot use fail - STMicroelectronics Community

 

If you're using HAL functions, you need to abide by their rules. Calling HAL_UART_AbortReceive to abort a transmit still makes no sense.

"If you feel a post has answered your question, please click ""Accept as Solution""."
YutinhLinAuthor
Associate II
February 23, 2026

This is a very strange phenomenon, but you don't see it as a problem.

Okay, I tried using HAL_UART_AbortTransmit() to stop the DMA transfer, but the same HAL_UART_Transmit_DMA() didn't work.

The error code for huart->gState changes to 0x32.

This is my call enable and disable function :
void CO_DMA_CRL(FunctionalState state)
{
if(state==DISABLE)
{
if(HAL_OK==HAL_UART_AbortReceive(CO_INFO.channel))
CO_INFO.dma_status=DISABLE;
if(HAL_OK==HAL_UART_AbortTransmit(CO_INFO.channel))
CO_INFO.dma_status=DISABLE;
}
else
{
CO_INFO.RX.data = (uint8_t *)co_dma_rx_data;
if(HAL_OK==HAL_UARTEx_ReceiveToIdle_DMA(CO_INFO.channel,(uint8_t*)CO_INFO.RX.data,CO_UART_BUF_LENGTH))
CO_INFO.dma_status=ENABLE;
}
}

Then I tried adding reinitialization:
MX_DMA_Init();
MX_BDMA_Init();
The error code for huart->gState became 0x33.

The HAL library was originally intended to be easy for developers to use.
Furthermore, why do the TX settings of DMA interact with the RX settings?

My initial use case was that I needed to reset the receive index to 0 each time.
As I mentioned in another post,When TX calls DMA, does the state not automatically return to IDLE after data transfer is complete?

The problem is that when using the HAL library, DMA TX fails to function properly after using HAL_UART_AbortReceive(), and re-executing MX_DMA_Init() and MX_BDMA_Init() also fails.
Do you mean I should abandon the HAL library and study the specs myself to achieve my desired development goals?

TDK
Super User
February 24, 2026

If you provide the actual code being used that replicates the problem, I will check it out.

Break it down into a few different HAL_* calls that illustrates the issue, like I did in your other thread with code that works. Not just function names, but actual code.

"If you feel a post has answered your question, please click ""Accept as Solution""."