STM32G474 DAC DMA: Data Alignment Issue

[Saeid]

Hi,

I am using an STM32G474 DAC with DMA and TIM6 trigger.

My sine table is:

uint16_t sine_table[SINE_SAMPLES] =
{
    2047, 2248, 2446, 2641, 2831, 3012, 3185, 3346,
    3495, 3630, 3749, 3853, 3939, 4006, 4055, 4085,
    4095, 4085, 4055, 4006, 3939, 3853, 3749, 3630,
    3495, 3346, 3185, 3012, 2831, 2641, 2446, 2248,
    2047, 1846, 1648, 1453, 1263, 1082, 909, 748,
    599, 464, 345, 241, 155, 88, 39, 9,
    0, 9, 39, 88, 155, 241, 345, 464,
    599, 748, 909, 1082, 1263, 1453, 1648, 1846
};

I found that this configuration works:

Memory data alignment:      Half Word
Peripheral data alignment:  Word

But this does not work:

Memory data alignment:      Half Word
Peripheral data alignment:  Half Word

Why does the DAC require Word (32-bit) peripheral alignment even though the DAC data is only 12 bits?

Also, how do I know which peripheral requires Byte, Half Word, or Word DMA data alignment?

Is there a general rule or a specific register description I should look for in the reference manual?

[MM..1]

If you setup only one DAC channel half word work, but best for CH1 CH2 is double DMA mode read 32 and write too 32 on one step.

[Saeid]

Hi ​@MM..1 

thanks for your reply, 
I only use one cannel DAC ( DAC1_Output1), but with half word peripheral data width is not working. As soon as I change it to “word” it start working. I would like to understand the logic behind it ? 

[AScha.3]

Hi,

In G4 series the data bus needs 32bit access always, if using DMA you have to set it to 32bit, even if you only want use half word.

 

[Saeid]

Hi ​@AScha.3  
Can you please point me to a reference document for this ? 

Does this mean for any peripheral  I should use “word “? if so, why CubeMx has : Byte, Half word, word options ? 

 

 

[AScha.3]

Just see the RM, rm0440 .

And ask the Ai , sidekick here:

## Summary

The available information points to the **STM32G4 Reference Manual RM0440** as the document that explains this requirement for the **DAC + DMA case**: the **DAC is directly on the AHB bus and its registers allow only 32-bit access**, so the **DMA peripheral transfer size must be set to WORD (32-bit)**; using half-word or byte access can generate a **DMA Transfer Error**.

## Detailed Explanation

### Which document shows it?
The information available identifies **RM0440** as the relevant document for STM32G4, specifically for understanding why **DMA must use 32-bit transfers on the peripheral side when writing to the DAC**.

### Why 32-bit has to be used
The reason given is:

- the **DAC is directly connected to the AHB bus**
- its **registers only support 32-bit access**
- therefore, the **DMA peripheral data width must be WORD (32-bit)**
- if a smaller width such as **half-word** or **byte** is used, the DMA can raise a **Transfer Error**.

### Important scope note
The information available supports this specifically for the **DAC on STM32G4**, not as a blanket rule for **all DMA transfers in the entire G4 series**.

If you want, I can narrow this further to the **exact RM0440 chapter/register section for DAC/DMA behavior**. **Do you want me to look for the precise RM0440 section reference?**

[MasterT]

Just see the RM, rm0440 .

And ask the Ai , sidekick here:

**DAC is directly on the AHB bus and its registers allow only 32-bit access**, so the **DMA peripheral transfer size must be set to WORD (32-bit)**; using half-word or byte access can generate a **DMA Transfer Error**.

Seems to me like re-phrasing question to: “What peripheries are Directly connected to XX-bus and what not?”

I don’t know answer, but usually RM  mentions some “packing /unpacking”  if no direct connection. SPI probably not directly connected, because it has this wording.

 If bandwidth of DMA is concern, than for DAC there is doublemode is implemented, G4 can drive DAC at 28 MSPS or so,  overclocking 15 MSPS DAC twice

[Richard Li]

BTW, I didn’t use AI, I did answer same question at “Bytewide DMA to a port: RAM to PD8-PD15, with a timer PWM used to generate /WR signal” 2 months ago.

[waclawek.jan]

> What I was hoping for was someone pointing me to the exact section of RM0440 that explicitly explains this behavior.

Well, you are quoting exactly the portions of RM0440 which detail the access width requirements - this is individual for each peripheral and thus it’s described individually at the beginning of register description for given peripheral.

Sadly, ST is not consistent enough in giving this for *every* peripheral; so where not given explicitly, one has to assume 32-bit access only.

There’s one more detail to this, although it’s also undocumented - the AHB-APB bridge (most of the peripherals are behind this bridge on an APB bus). So what the busmasters (processor, DMA) “see” is combination of the bridge’s and peripheral’s behaviour. One particular outcome of this is, that for example in STM32F4xx (and many other families if not all), if one writes a byte into a 32-bit timer register, this value gets duplicated to all four bytes of the 32-bit word, e.g. writing 0x1A into such timer register results in 0x1A1A1A1A being written. This gets very surprising when one ports code from e.g. ‘F1 to ‘F4, where timer registers are written using DMA - in ‘F1 there’s a single-port DMA which (if set to byte-to-word transfer) itself performs zero extension; but in ‘F4 the dual-port DMA does not zero-extend: if set to Direct (non-FIFO) mode it ignores the memory-side width so in case of byte-to-word transfer it ignores the “byte” width and reads words; if set to FIFO mode and byte-to-word transfer it reads four bytes at source and concatenates them (with the net result being the same as in Direct mode just taking more cycles); if set to byte-to-byte transfer, regardless of Direct or FIFO, the byte-width write results in the duplication at AHB-APB bridge as described above - so the only solution is to use a word-width memory array, “wasting” space for zeros.

JW

[MasterT]

 

IMHO, a lot of confusion comes from DS table 89, which gives a false illusion about DMA transforming magic capability from any source size to any destination size. (And dropdown boxes in the STMCubes do the same things). Nothing of the kind. It should be stated that DMA is always a 32-to-32 device. 

When an 8/16-bit limited peripheral needs to talk with 32-bit forever DMA, it must have some hardware logic to do packing/unpacking. These hardware logic elements may be integrated into FIFO or may not. 

So, if we see that the ADC is capable of "squeezing" two data (<=16 bits) samples into one 32-bit DMA word, it means packing logic was built into the ADC. And if DAC is not managing splitting service 32 down to two 16-bit, it simply means there is no hardware unpacking logic designed to do so. 
It has nothing to do with DMA. Just exceptionally interfacing bolted-up peripherals' features. 

And if some timers repeat a byte 4 times all over a 32-bit word, it's simply a timer's problem. Errata. DMA/Bridges/AHB/APB should not ever care about misunderstandings from the receiver side.