STM32H7 MDMA-MDA chaining

[bigfoot]

I have difficulties with the following scenario:

There is a big buffer of bytes in DTCM memory. The buffer should be transmitted out through UART or SPI. I'm looking for solution, where software only configures the transaction, and then the whole process is done by hardware automatically.

As DMA1/2 cannot work with DTCM, we need to use MDMA.

The simplest implementation is as follows:

• Define small (say, 128 bytes) buffer in SRAM2
• Configure MDMA to transfer the DTCM buffer to SRAM2 buffer by portions of 128 bytes
• Configure DMA1 or 2 to transfer SRAM2 buffer to the peripheral

Unfortunately, there are gaps in this scheme:

1. MDMA and DMA should be chained to work intermittently. While there is direct mechanism to start MDMA at the end of DMA transaction, I do not see a simple way to start DMA at the end of MDMA transaction.
2. I was advised to configure and start DMA in additional block of MDMA. Unfortunately, it breaks the simplicity: instead of simple MDMA configuration, we need to build a long linked list of intermittent fill-buffer and configure/start-DMA blocks.
3. If DTCM buffer length is not multiple of 128, the last transaction in both MDMA and DMA should be less than 128.

If anybody knows solution, or can point out relevant example, any help will be highly appreciated.

[MM..1]

Maybe you need correct subject to MDMA - DMA .

And because UART or SPI is slower as MDMA, is ideal oposite way DMA will request MDMA on half and full IRQ complete.

And i mean without some IRQ code your idea dont will work as complete offload MCU.

[bigfoot]

>> Maybe you need correct subject to MDMA - DMA .

Sorry, I didn't catch your point.

>> And i mean without some IRQ code your idea dont will work as complete offload MCU.

So, you consider the hardware cannot acomplish this work without software assist.

Maybe; however MDMA seems rather close to this purpose. Probably, very simple additions to the hardware would provide support of this scenario and many other useful scenarios.

[TDK]

There's no way to chain MDMA and DMA like this without any intervention of the CPU. Note practically, at least. You could do awkward things with timers triggering the DMA transfers.

If you can't devote even 20-30 ticks to start the DMA after MDM is complete, a simple solution would be to use SRAM2 instead of DTCM.

[bigfoot]

Thank you, guys.

Software-assisted solution was implemented before.

Simply looking for better solution.

[alexandre23]

It seems that mdma linked list is made for that purpose, as you said in your first post. It's a little bit cumbersome to write all the mdma blocks, but it will work without cpu intervention. I use that solution in a project, but had to resolve a problem on the trigger event to load next linked mdma block. I have found workaround, first software assisted, then hardware assisted, but it still look hackish, more details here : https://community.st.com/s/question/0D53W00000xsRELSA2/mdma-linked-list-unconditionnal-trigger-to-next-block

[bigfoot]

Thank you Alexandre.

Your solution is really sharp. However, you are correct, it looks like a hack.

For a while, I can live with software-assisted solution.

Actually, I have impression that MDMA, although sophisticated, is a bit raw. With addition of relatively simple hardware, it would be able to support many useful scenarios that currently are not avilable or require awkward hacks.

Few simple additions are evident:

• Ability to start DMA directly on MDMA end
• Global byte counter that ends MDMA operations irrespective of blocks, linked lists, etc.
• Extended buffer-driven operation, source/destination address manipulation in the end of buffer transfer

[Ghudw.1]

It seems that mdma connected list is made for that purpose, as you said in your first publish. It's a little bit cumbersome to write down all the mdma blocks, but it will work without CPU intervention. I use that answer in a challenge, but needed to solve a hassle on the cause event to load subsequent related mdma block.