Using UART in DMA mode

[Mohammad A]

Posted on April 08, 2017 at 00:00

I am trying to implement UART in DMA mode to transmit a simple string every time a push button is pressed.

So I have used CubeMX to generate the code and I have configured UART2 TX DMA in normal (not circular) mode and also no FIFO and no burst.

Whenever I run the code in debugging mode, I see the first time I attemp to send the string, it works ok and sends the string, but inside the DMA IRQ handler, it calls TxHalfCpltCallback and not TxCpltCallback and also UART gState will remain in BUSY mode so I can't use it to transmit no more string.

My Question is why it calls TxHalfCpltCallback and not TxCpltCallback? and how should I handle it (because HAL reference says it waits for sending the second half of buffer! what?)

And also, would sending the next half of data relase the gState of UART?

#uart #dma

[S.Ma]

Posted on April 08, 2017 at 08:29

Are you sure not to be using the double buffer mode for continuous sending of multiple memory blocks?

[Mohammad A]

Posted on April 08, 2017 at 09:43

Where is double buffer mode to configure?

IDK about it!!!

I have attached a report of configurations, please take a look at DMA page

Thanks in advance

________________ Attachments : report.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hyir&d=%2Fa%2F0X0000000bBY%2FUXp9XrHk3VyhdEY3foKaWweXwu6Fq6nJAV0Fb6RxDEA&asPdf=false

[Tesla DeLorean]

Posted on April 08, 2017 at 17:44

The inference is that you're going to need to cross check the code that Cube generates, and determine WTF is going on in the HAL with all the circular logic and blocking, and whether things should be called in interrupt context or not.

One of the key problems seem to be the lack of 'dog fooding' within ST to use these tools to create anything moderately complicated or deliverable.

[Mohammad A]

Posted on April 08, 2017 at 17:54

I have reviewed the code many times, but tge lack of efficient documents, prevents me to understand what tge hell is going on and how I should handle single/double buffer mode and what to do when half transmit call back is called. I will attach the code when ASAP

[Tesla DeLorean]

Posted on April 08, 2017 at 19:39

I can't support HAL/Cube code issues.

[Mohammad A]

Posted on April 08, 2017 at 22:38

it's a bug, it enables HTIE regardless of user configurations with only one memory address, thus prevents transfer to complete.

[S.Ma]

Posted on April 09, 2017 at 09:11

Then go for low layer cube library (if confortable enough). What is the baudrate and sysclk value in the application? Which device?

[Mohammad A · Accepted solution]

Posted on April 09, 2017 at 09:46

OK, I have figured out how to solve this problem. as Nesrine M has replied in this thread:

https://community.st.com/0D50X00009XkfT3SAJ

, it is mandatory to enable HAL_UART_IRQHandler() , this is because uart irq handler function will reset gState.

My

previous reply was my mistake to understan how HAL handles this, but I think ST must explicity mention in HAL driver that enabling HAL_UART_IRQHandler() is required.

[Jeff C]

Posted on November 07, 2017 at 15:58

For those looking for the location to 'fix' this issue as noted in the solution:

  STM32CubeMX -> Configuration Tab -> USART# Oval Button -> NVIC Settings -> USART# Global Interrupt -> Enabled [Must Check if DMA in Normal Mode]