cancel
Showing results for 
Search instead for 
Did you mean: 

When using DMA to tranfer data of UART, what will happen if Bit20 TRBUFF of DMA_SxCR is not set?

GWang.5
Associate II

I am using the UART of STM32H747,with DMA transfering data. There is a Note in the reference manual about DMA_SxCR register:

0693W00000WIb6AQAT.pngAnd in the Errata sheet of STM32H743, it says:

0693W00000WIb6tQAD.pngWhat does a concurrent transfer mean? Will the DMA channel transfering UART data be locked? What are chances the DMA channel be locked? How can I make the lock happen in my own project?

6 REPLIES 6
RomainR.
ST Employee

Hello GWang.5 (Community Member)

Welcome on ST Community.

A concurrent transfer means DMA is performing another transfer request with other peripheral than USART. 

DMA protocol is based on state machine between peripheral request and DMA acknowledge. The peripheral request is cleared when dma acknowledge is asserted.

When using TRBUFF=0, if the application uses several dma transfer with several peripheral (for example ADC and USART). If DMA acknowledge take longer time than expected to clear ADC request, and if at this time an USART request appears, USART transfer will be not served, and DMA stream may stay locked.

With TRBUFF=1, the same issue will not happen because the ADC DMA ack is cleared immediately after AHB transfer completion is ready. So, if USART send DMA request, it will be served.

TRBUFF bit acts as workaround.

Best regards,

Romain

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

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.

Hello Romain

Thank you for your answer, but I still have some questions. For clarity, I quote your answer in "bold italic" style.

Q1: Does "The peripheral request is cleared when dma acknowledge is asserted." mean "The peripheral request is cleared when dma acknowledge is asserted set"?

Q2: If the answer to Q1 is yes, should "ADC DMA ack is cleared immediately after AHB transfer completion is ready", be "ADC DMA ack is cleared set immediately after AHB transfer completion is ready"? Or it can't clear the ADC request, and "if at this time an USART request appears, USART transfer will be not served, and DMA stream may stay locked."

Best regards,

GWang.5

Hi Romain,

Thanks for this information. However, it rises more questions.

Are we talking about the dual-port DMA here, as is also in 'F2/'F4/'F7?

Is this information relevant for 'F2/'F4/'F7? If not, why not? Is it then relevant to presence of DMAMUX in 'H7?

Is this information documented in RM or at least the relevant AN?

Why is this flag relevant only for UARTs? How are UARTs' requests handled differently from every other peripherals'?

What happens if this flag is set with any other peripheral?

And perhaps the most intriguing question:

> With TRBUFF=1, the same issue will not happen because the ADC DMA ack is cleared immediately after AHB transfer completion is ready.

How and why does a flag set for a stream handling UART request influence an obviously different stream set for ADC requests???

> If DMA acknowledge take longer time than expected to clear ADC request,

Can you please specify "longer time than expected"? What is the "expected" here? The "AHB transfer" you are referring above is the peripheral-side transfer? If the flag in question is not set, when is this request cleared if not at the moment when the peripheral-side transfer is fulfilled? What *exactly* is the timing sequence and what are the consequences?

Also, why would one stream taking longer to complete *clear* *other* stream's request?

This last question is unsettling that at this point I don't even believe you that the flag you propose to use is able to completely resolve the problem without any other "buts" and "maybes" and "let's hope that nobody runs this combination".

> DMA stream may stay locked.

What does this mean? Is this DMA stream being locked until reset no matter what, or the fact that not handling UART request by reading/writing UART's data register results in no more UART requests? In other words, if I detect in some way this "locked" state (e.g. by observing UART behaviour by program) and then say reset UART so that it generates the request again, would this make the stream resume or not?

I'm asking in order to gain deeper understanding of the various inexplicable failures of the dual-port DMA in 'F2/'F4/'F7 we've seen and discussed here (I am lazy to look up ancient threads where I've shown how to lock up a 'F4 DMA stream by temporarily disabling a request) and elsewhere (see e.g. 'F40x errata) for years.

I understand that digging deeply into an obviously very complicated logic is not simple, easy and may result in overwhelming amount of information; but in my opinion, clear, concise and complete information makes in the long term better product than vague statements and broad handwaves.

JW

Hello GWang.5.

To clarify this:

Q1 -> Answer1:

Yes, peripheral request  is cleared when DMA acknowledge is set.

Refer to RM0399: 16.3.4 DMA transactions:

Q2 -W Answer2:

The ADC DMA ack is cleared immediately after AHB transfer completion is ready.

Best regards,

Romain,

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.

Hello waclawek.jan (Community Member)

Yes, this concerns the dual DMA, but the limitation is on the USART side, not in the DMA.

You are right, this is not documented in the reference manual, but this workaround is explained in the Errata Sheet ES0392 USART limitation section 2.13.2.

Best regards,

Romain,

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.

Hello Romain

Thank you for your answer, but I still have some questions.

Q1: According to RM0399: 16.3.4, the action of request and ack can be divided into 4 steps. In which step does "DMA acknowledge take longer time than expected to clear ADC request" hapeen?

step1: peripheral sends request to DMA (request set)

step2: DMA sends ack to peripheral (ack set)

step3: peripheral releases request as soon as it gets the DMA ack (request cleared)

step4: DMA ack is released as soon as request is released (ack cleared)

Is it in step3, peripheral gets DMA ack later than expected? Or peripheral doesn't release request although it has got ack?

Is it in step4, DMA ack is not released although request is released?

Q2: What does "AHB transfer completion is ready" mean? Does it mean AHB is ready for current DMA transfer or current DMA transfer is complete, or else?

Q3: What is the condition for "AHB transfer completion is ready" ? If "AHB transfer completion is ready" comes late, DMA ack is also cleared late, then how can the DMA lock be avoided?

Best regards,

GWang.5