Can peripheral-to-memory or memory-to-memory DMA be transfers be configured to substitute for lack of peripheral-to-peripheral features in the Cube toolchain?

[KHarb.1]

I need to load the TIM1 CCR registers into the DAC1 outputs on an STML432KC. I have this working with the line DAC1->DHR12R1 = TIM1->CCRx executing in a loop. I'd like to substitute with DMA.

Others have suggested that I can do this with the available DMA features and supplying the the necessary register addresses. I gave it a shot and couldn't make it work. However, this is my first STM32 project, and I'm new to the toolchain.

Is this approach really viable?

[Tesla DeLorean]

>>Is this approach really viable?

So you're going to replace a transfer that's triggered with one that basically runs in saturation?

You need to determine which DMA resource is triggered by TIM1 CCx, or find a different TIM.

The Reference Manual should show the relationship. And the DMA unit that's triggered by the TIM should be able to read any of that TIM peripherals registers as a Peripheral Source.

[KHarb.1]

The DMA is intended to be triggered. There are two signals with the same frequency with varying phase offset. One signal clears the timer and the other registers the input capture to yield the relative phase. Sending the capture register to the DAC yields an analog version of the varying phase offset. Either signal can be used as the DMA trigger.

Regarding DMA resources: I let Cube set that up by setting up DMA options within the DAC config menus. I then called HAL_DAC_Start_DMA and give it the the address of the capture register. Nothing appeared to happen. Since Cube doesn't know the destination address during config, it might not know it if linking DMA to TIM1 is somehow not allowed.

[KHarb.1]

Using the Cube menus for help, I can see:

TIM1 menus give CH4 DMA1 channel 4

TIM1 menus give CH2 DMA1 channel 3                              

DAC menus give channel 1 DMA1 channel 3

DAC menus give channel 2 DMA1 channel 4.

So..there's a way to make the channels match...but I'm only guessing as to what the user-supplied input commands might be. It seems like running the the start commands for both ends of the DMA channel will break things.

[LCE]

A good example for what CubeMX is good for: a quick check of what migt be possible concerning the DMA channels.

Forget CubeMX otherwise as "part of the toolchain", I recommend seeing / using it only as a basic setup tool.

Anyway...

> It seems like running the the start commands for both ends of the DMA channel will break things.

Definitely. If a DMA channel is already in use, you cannot start it again.

But what you could try - no idea if that works - is a peripheral-to-memory DMA transfer, with the TIM as the peripheral and the DAC register as destination address.

Trial and hopefully not too many errors... ;)

On the other hand, if CCR doesn't trigger too often, maybe you could put this DAC1->DHR12R1 = TIM1->CCRx into the TIM's CCR-ISR ?

[KHarb.1]

The application is going keep the MCU strapped on cycles...so no ISRs for this part. I tried what you mentioned above with the DMA channels matched, but still nothing.

I'm new as of this week to STM32, so I'll take any advice on how to move on.

[LCE]

I just saw your other thread, there you started the DAC DMA with CCR as source.

Maybe you should try the other way, TIM DMA transfer, peripheral (CCR) to memory (DAC), because the CCR event should trigger the DMA transfer.

[KHarb.1]

I've tried both of those, and also tried setting up memory to memory DMA channel via the DMA menus. If done right, it seems like all three should do the same thing...but I'm so new that I have no good way to tell if the DMA isn't triggering or there's some other config issue...or its all locked and not possible. It would be great if ST could weigh in.

[KHarb.1 · Accepted solution]

Changing CPAR and CMAR registers after DMA init does what's needed. As long as they reconcile with the direction bit, I'm not sure it matters which address goes into CPAR and CMAR.