MDMA slower than Memcpy and much more noisy

[Robmar]

Using STM's MDMA example, I setup a simple loop to transfer an array of 1000 bytes 100 times.

The code worked but the MDMA transfer were causing glitches on the VDD rail.

I then compared it to memcpy, and to my surprise found that it was around 18% faster than MDMA, and did not generate the nasty glitches on the VDD rail.

Instruction caching is enabled, data caching disabled.

Is this behaviour as expected?

[SofLit]

Hello,

Share your implementation using the button:

or better attach your project (a simple project) that reproduces the behavior you're seeing.

What is the board you're using?

[Robmar]

Hello Ms/Mr ST employee, thank you for your reply.

As I wrote, it is the STM example MDMA project, there is only one that lists in the STM32CubeIDE list of examples, here are the instructions to make the test:-

1. Download the STM MDMA example and compile.

2. Modify the code with a for-loop to move 1000 x 800 byte blocks within AX2 memory, taking the time with HAL_GetTick() before and after, note the time elapsed.

3. Using a similar for-loop, replace the MDMA with memcpy, and check the time elapsed.

My test doing this repeatedly shows memcpy to be faster and creating less VDD noise spikes.

If you're unable to do this without my 10 lines of source code, please keep scrolling because you won't be capable of analysing the situation.

Sorry, but this is a very very simple test and I'm looking for someone who knows how to use MDMA.

[Bob S]

> f you're unable to do this without my 10 lines of source code, please keep scrolling because you won't be capable of analysing the situation.

Really?  THAT is the tone you want to set when asking for help on this forum?  From other people?  For FREE?  Common courtesy would suggest you provide as much as possible to make it as quick and easy as possible for anyone else to replicate your situation.  Sheesh!

[Robmar]

haha funny, well SofLit hardly started with a good attitude demanding "Share your implementation!"

And hey, this is not free, as a company we spend a fortune on ST MCUs, so this is paid support.

The only "implementation" is a for loop with a call to an MDMA or memcpy function, as I wrote.

Personally, I've made it clear to Remi Al-Ouzanne (ST MCU President)  and the Mssr Cherry (overall President) that I am not impressed with ST technical support or resources, and to be honest your idea of how to treat a client does not bode well.

[Tesla DeLorean]

It's not that it needs to be fast, but rather that you can do other productive things whilst it is happening.

The best approach is NOT to move things at all, and have a DMA unit that has a scatter-gather list so the mechanics that get the data off-board can cherry pick subsections, and pull headers from different locations.

[Tesla DeLorean]

My experience is solid technical skills appear to have little value here..

[Robmar]

yeah, but it's so slow the code ends up waiting for it to finish anyway, and it's noisy.

As you know, the whole point of hardware based DMA, or Memory-DMA, is for it to be faster than the CPU, and to not create spikes on VDD.

"The best approach is not to move things", you're making a big generalisation, how can we not move things on the screen, really?!

We're scrolling an SDR waterfall, which is memory mapped to the display, so it's efficient, or would be if MDMA was any use.