cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4 receive DMA timeout

alexander239955
Associate II
Posted on February 09, 2015 at 17:59

Hello,

I have to realize receive DMA timeout for a serial interface. I found the application note AN3109 which describes a mechanism to realize a DMA timeout for the STM32F10x microcontroller. Does this application note also apply for the STM32F4 family?

Basically they recommends to use a timer in slave reset mode, whose counter is reinitailized in response to rising edges on an input capture connected to the UASRT receive pin.

Has somebody an code example for the STM32F4 family which shows this mechanism.I tried to use CubeMX to generate the initialising code but I failed.

Thanks in advance

Alex

#usart-rx-dma
7 REPLIES 7
Posted on February 09, 2015 at 18:11

> Basically they recommends to use a timer in slave reset mode, whose counter is reinitailized in response to rising edges on an input capture connected to the UASRT receive pin.

I don't know how is it in 'F1, but in 'F4 and 'F2 the GPIO-AF-matrix won't allow you to use a pin as USART-Rx and TIM_CHx simultaneously; the matrix is a true multiplexor.

You still can connect the Rx signal to two pins externally.

JW

Posted on February 09, 2015 at 18:23

An additional observation, which might help, although is not as good as the solution on 'F1: even if you can't share an input pin between peripherals of different AF, you still can use it as a GPIO (that's not that relevevant here), and as an EXTI source. Thus, you could set up a timeout in an EXTI interrupt, if the system is not too busy to allow such an interrupt.

JW
jpeacock
Associate III
Posted on February 09, 2015 at 19:45

You have to use a timer that has an input capture pin and resets the counter on every transition.  I use timer TIM9 channel 1, trigger on both edges, UEV interrupt only on overflow.  Connect the capture input pin to the RxD pin on the USART.

Set up a regular RX interrupt for the first character in the messages.  When it arrives switch to DMA mode for the rest of message and start the RX timer.  At the end you get a buffer with the entire message, based on the timer overflow interrupt.

The goal is to set the timer for whatever the inter-message gap will be, and then wait for the timer to overflow because no data in the bit stream is resetting the timer count.  When the timer interrupt occurs I stop the RX DMA on the USART channel as that interrupt is effectively a message framing mark.  This technique assumes you can guarantee there is a burst of data framed by gaps longer than the time between bytes in the message.

I've used this with RS-485 at 460Kbits/sec with very low CPU overhead due to DMA, and using the separate 16KB SRAM space in an F4, bus access runs in parallel.

I don't own the code, can't post it.

  Jack Peacock
alexander239955
Associate II
Posted on February 10, 2015 at 09:17

Hello Jack,

I am now a little bit confused. Jan wrote in his post, that ''GPIO-AF-matrix won't allow you to use a pin as USART-Rx and TIM_CHx simultaneously''. You on the other hand wrote in your post, that you used on a STM32F4 with exactly the mechanism which I intend to use. But how do you configure GPIO pin? Do you switch the GPIO AF function to USART-Rx or TIM_CHx ? Kind regards

Alex

Posted on February 10, 2015 at 10:28

>

Do you switch the GPIO AF function to USART-Rx or TIM_CHx ?

You have to use two externally connected pins.

I looked at AN3109 and they do it in the same way.

JW

alexander239955
Associate II
Posted on February 10, 2015 at 16:04

Hello Jan,

thanks for your help

Alex

jpeacock
Associate III
Posted on February 10, 2015 at 19:48

On the F2/F4 alternate functions for a pin can't be shared since the AF registers only allow one function to be selected.  I use a separate pin for the timer input.

Your intention to use DMA RX timeout is a good one.  It dramatically reduces USART overhead compared to character RX interrupts, especially at high speeds.  Same for sending blocks with TX DMA, combine with overlapped bus access on an F2/F4 and USART data transfers come close to being ''free'' in terms of CPU resources.

  Jack