cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L073 DMA Simultaneous RX and TX

DPast.1
Associate II

I've been trying to get simultaneous RX and TX working on USART2 of a STM32L073 and have not been able to get it to work. I've messed around with priorities, order of enabling DMA transfers, etc but always the TX DMA transfer succeedes and the Rx DMA transfer fails.

Looking through the reference manual it suggests to me that perhaps this isn't possible on this device as it states that two DMA transfers cannot have the same request number. When using DMA RX and TX on the same channel with this device unfortunately it appears that the same request number is required.

Does anyone know if it is possible to do simultaneous RX and TX on the STM32L073?

7 REPLIES 7

Pretty sure the hardware is capable of this and more, and the RX and TX will be on different channels. Going to pull the RM now

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

So yes enough channels to do RX+TX on USART1, USART2 and LPUART1 **CONCURRENTLY**

Transfer speeds orders of magnitude slower than the Bus and DMA are capable of, so priority is a complete non-issue.

0693W00000GZyopQAD.jpg

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

I expected the same as it seems like a pretty basic thing to do. The reason I think it might not be possible is the paragraph above that page:

Where is states that two different channels cannot have the same request, in this case #4. This seems rather strange to me as having Tx and Rx on the same channel would be something I'd expect to be able to do.

0693W00000GZyv1QAD.png

What happens right now is it tells me the TX DMA completed (even though no data was pushed out) and the RX DMA did not complete. I did previously have the RX DMA working perfectly when using a for loop to push out TX data, but I was hoping to use two DMA transfers and just put the processor to sleep.

TDK
Guru

The TX request is different than the RX request. The Caution note is saying you can't map, for example, USART2_RX to two channels simultaneously.

If RX DMA did not complete, perhaps data is not coming in, or there are issues with it such as framing.

Perhaps also look more into claim that no data was pushed out. Verify pins are configured appropriately, etc.

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

Right, but I think that caution is that USART1_TX can't be serviced by Channel 2 and Channel 4 at the same time.

The logic in the IC can't prevent you from doing that, as the channel's MUX is independent, and both will try to service the request, with unpredictable hilarity ensuing.

But USART1_TX_DMAREQ and USART1_RX_DMAREQ are TWO entirely different signal sources, derived from the TXE and RXNE status out of the units. They might share a common index number for the individual muxes, ie USART1 source, but the associativity is fixed and to different independent sources.

I'm using USART DMA on an L072, and my recollection of that implementation is that the RX DMA is Circular feeding a fixed circular buffer that's periodically harvested, and a TX DMA which is fed from a chain/scatter-gather type arrangement in one-shot mode.

The sort of failure you're inferring would get caught in validation, for sure, or there would be a firestorm of complaints/reports.

That's not to say you aren't having difficulty, or discounting that, but I think you should focus on the SW side, and not the HW as the cause here. And again, don't think it's a priority issue. Could be a direction/width issue. You'd need to double check settings, and look for error/status reporting, and HAL..

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Ahhh, that makes sense. I didn't think of it in that way. I'll keep plugging away at this then, I'm sure it's something simple that I'm doing wrong and likely a result of me copying and pasting something without making the right changes.

That's great to hear and thank you all the information! I'll take a look at the hardware registers in the debugger and see if they match what I think they should be.

Thanks again!