STM32F4 USART2 TX using DMA (with StdPeriph_Driver)

[dennis2399]

Posted on September 22, 2015 at 14:58

 

 

The original post was too long to process during our migration. Please click on the attachment to read the original post.

[waclawek.jan]

Posted on September 22, 2015 at 15:14

Divide et impera: UART Tx alone works (perhaps in a loop, avoiding DMA in the first step)?

JW

[keaven]

Posted on September 22, 2015 at 15:52

It is not in your post but do you have yourUSART2_IRQHandler() ? You need it even if you are using the DMA.

Like this

void USART2_IRQHandler(void)
{
HAL_UART_IRQHandler(&hUART2);
}

This is with HAL library but you still need to manage your UART Flags in the IRQ.

[Tesla DeLorean]

Posted on September 22, 2015 at 15:53

I suspect there will be issues with pacing (no flow control between two streams), and there's inconsistency in data size, ie 16-bit data, vs 8-bit data.

So you'll want to think about the disparity between the data rates, consider using HT/TC for the ADC, and then lighting off a Normal DMA transfer to the USART from the alternating halves of the ADC buffer.

I think I've posted a couple USART TX DMA examples, including ones that cycle through multiple strings (aka buffers).

[waclawek.jan]

Posted on September 22, 2015 at 16:24

> It is not in your post but do you have your USART2_IRQHandler() ?  You need it even if you are using the DMA.

Certainly not.

> This is with HAL library but you still need to manage your UART Flags in the IRQ.

Certainly not; contrary, you need DMA to handle them.

JW

[keaven]

Posted on September 22, 2015 at 17:12

You are right!  I have it for my transfer complete interrupt on TX.

[dennis2399]

Posted on September 23, 2015 at 11:53

I appeared to be missing a line in my GPIO config for the TX pin.

/* Connect USART pins to AF */
GPIO_PinAFConfig(GPIOA, GPIO_PinSource2, GPIO_AF_USART2);

After using this I got it working at the 115200 baudrate, after upping this to 2625000 I had to use the oversampling command. Using no flow control seems to work when using a terminal program but I guess it could be added for more stability. I guess I don't need any of the USART IRQ handlers since, I configured DMA1 to handle the USART Tx requests with the following line:

/* Enable the USART Tx DMA request */
USART_DMACmd(USART2, USART_DMAReq_Tx, ENABLE);

Since both DMA streams are not running parallel but one after another this seems to check out. The mismatch of 16-bit ADC values being transferred over an 8-bit USART line is currently being handled on the receiving end where I perform an fread which expects uint16 values. It's not flawless yet but I'm on my way :) Thank you already for all of your responses!