Can TIMx OC DMA events be used to load DACs from memory?

[KHarb.1]

I want to vary the duty cycle of two adjacent DAC values of an STM32G473.  I am using DAC1 channel1 and channel2 for the output. I want to load DAC1s DHR12Rx registers via DMA when TIM3 hits output compare values.  I set up a memory to peripheral transfer for each TIM3 channel and set the CMAR and CPAR registers to the memory location of the DAC values and the peripheral addresses of the DAC DHR12Rx registers.  

I have been able to make this configuration work for making the TIM3 OC events trigger loading of TIM20's CCR registers from memory, but so far, the DMA transfer won't load the DHCR12Rx registers for the DACs.  Are there additional configuration settings to make this work? 

CubeIDE\HAL has configuration options for initializing the DAC in DMA mode, but I need multiple triggers the make the duty cycling work.  

[waclawek.jan · Accepted solution]

I personally would do this differently - I would use TIMx Update-triggered DMA to load varying period to TIMx_ARR, and then use the same TIMx Update as TRGO source, with setting DAC to be triggered natively from TIMx_TRGO; and then would load the DAC data using DAC-triggered DMA. But you do you.

At any case, debugging starts with reading out and checking relevant registers' content.

But let me make a wild guess: you've set the DMA into DAC to be other than a word (32-bit) wide; that would not work.

JW

[KHarb.1]

Wow. Very nice. Changing the data size made it work.  In this mode, only one timer is needed and configuring it is simpler to get the desired behavior. 

[Ozone]

> But let me make a wild guess: you've set the DMA into DAC to be other than a word (32-bit) wide; that would not work.

As far as I understand it, this applies to the DAC dual mode, which the OP obviously employs.
I use 16-bit DMA to one DAC channel register, and it works fine.

> I personally would do this differently - I would use TIMx Update-triggered DMA to load varying period to TIMx_ARR, and then use the same TIMx Update as TRGO source, ...

This is the way most of ST's DAC-DMA examples do it. At least all the ones I have seen.

[waclawek.jan]

> I use 16-bit DMA to one DAC channel register, and it works fine.

In 'G4?

JW

[Ozone]

No, a F303.
I haven't worked with a G4 device yet, sounds like this devices have different DAC interface, again. 

The F3xx (at least the F30x) have 16-bit and 8-bit registers for individual DAC channels, and a 32-bit register for both channels to be used in dual mode.

[waclawek.jan]

The difference here lies in the fact, that in the 'F3 DAC is located at the APB bus, and the AHB-to-APB bridge is forgiving, i.e. it does not enforce access width. In contrast, in the 'G4, the DAC - quite inexplicably, to me - is directly at the AHB bus, and it's designed so that it does not support non-word-width accesses, and signals bus error to the master which attempts such access. In case of DMA, it results in Transfer Error and the given Channel being stopped.

JW

[Ozone]

Good to know.
As said, I didn't use a G4 device yet, and haven't looked at the reference manual.
I only hope this topic is properly covered in the G4 manuals...

[waclawek.jan]

Define "properly".

The 'G4 RM says, in DAC registers subchapter:

The peripheral registers have to be accessed by words (32-bit).

But the exact same sentence is also in the DAC registers in RM0316 for 'F3... 

The difference is, that if write 16 bits into DAC registers in 'F3, the AHB/APB bridge takes those 16 bits from AHB and quietly duplicates them to the other halfword to APB and does not assert the transfer error signal. This duplication is somewhat documented in RM0316 in 3.1.5 BusMatrix/AHB/APB bridges chapter.

What is "improper" here is the "integration" aspect of this - you can find the individual snippets of information which is directly related to the individual "components" (such as DMA, bus matrix, DAC), but these snippets are not brought together so it's left to the user to assemble the whole picture... This is the price we pay for the "lego"-style using which these chips are designed.

JW

[Ozone]

> Define "properly".

I rarely get into such details as inter-bus bridges and restrictions they impose - only if other readings that a project requires link to this chapters.

From a plain description of the DAC section with individual 16-bit output registers and the DMA section stating byte, half-word and word capability, this restriction is neither obvious nor makes it sense on this level.

> This is the price we pay for the "lego"-style using which these chips are designed.

For sure. I ran into similiarly vaguely described issues and differences between F30x variants that did cost me many hours of reading and testing.

By the way, one example I had based a recent (F303) application on uses the DAC dual mode, and employs 32-bit DMA transfers to the specific dual-mode 32-bit DAC register. Modifying it for 1 channel and 16-bit worked fine.