Hallo everyone,
Since some time I struggle to get DMA access working on a STM32H723. I was pointed out this MCU is a complicated beast, but I would at least expect sensible, coherent documentation for it.
When I look at page 683, I see:
on next page:
and on page 691:
At the bottom of page 672 I read:
These pieces of information confuse me: the register name in the headers are different from the ones in the Register Map, and it looks to me there is no register for 'DMAMUX2CRxC'.
Further, when I run the debugger on an application that intends to use DMA on SPI3_Tx, I failed to read the registers mentioned above in the column "Live Expressions", because I didn't know the correct names. Although the column 'SFRs' show:
combinations like: DMAMUX1_C2CR, DMAMUX_C2CR, DMAMUX1.DMAMUX_C2CR, etc. did not result in showing values. I find it quite an omission in the documentation that an user gets bits and pieces information andmust guess how to put it together to one coherent understanding. He/she should be informed about the naming rules in an understandable way.
Another complaint about missing explanation: at the bottom of page 678 is stated:
The DMAMUX request line multiplexer channel x selects the DMA request line number as configured by the DMAREQ_ID field in the DMAMUX_CxCR register.
Even after carefully re-reading this sentence many times, I cannot comprehend what it means. From another part of the text I understood "multiplexer channel x maps to DMA channel x", meaning that the request in the multiplexer channel x will result in activation of DMA<n>-Stream<m> (n=1,2 and m=0,7). Is this conclusion correct? And if this assumption is correct, does the DMAREQ_ID field in DMAMUX1_CxCR specify the 'DMA Request MUX input' in table 118?
I find it ridiculous that an user must guess how the source of a DMA request and the peripheral on which it is effectuated are not clearly explained. I have got the feeling to search blindfolded in a dark room with my hands tightened on my back for clues to understand and program DMA access by means of a DMAMUX. And it seems I'm not the only one how suffers from unclear documentation. I sincerely hope ST will read this request and takes it seriously.
Fred Schimmel
Hello Fred,
Thanks for a clear explanation on what is confusing. You have several questions, I will first answer to the register naming trouble.
For the DMAMUX register you have two set of register one for DMAMUX1 (in D2 domain):
one for DMAMUX2 (in D3 domain)
Usually in the peripheral description in reference manual the register name does not include the instance number of the peripheral:
and you find the exact same name in the register map:
when the instance of the peripheral differs, there is a note in the bits definition to explain the difference:
For the DMAMUX, the author find it more clear to detail the implementation of each instance of DMAMUX in the register description rather than giving many notes (obviously it is not your point of view). So he detailed DMAMUX1 registers and DMAMUX2 register giving them their full name (which includes the instance). In the register map the author sticked to the usual practice giving the name without the instance number, and giving the bit content of the full featured super set.
Below is an example of superset given in register map: bits 0 to 4 are present in both instance, and bits 5 and 6 are present only in Instance 1:
The debugger sticked to the current practice, it gives on top the peripheral name with the instance (1 or 2) and gives the register name without the instance.
Tell me if this part is more clear.
Jacky
> However, you didn't reply on the second part of my question: how should I specify a DMAMUX register in the Debugger column 'Live Expressions' and so in my code (my experience is these are the same).
These names come from 2 different files: in your program, registers names are defined as symbols in the CMSIS-mandated device header, wheras the debugger uses the so called SVD file. Unfortunately, ST is not always consistent in these (as they are not consistent in naming in RMs nor between RM and the two files, as you've already found out); even worse, sometimes the structs in CMSIS-mandated device header don't even reflect the structure of registers in RM and example code accesses them in some ad-hoc manner (see for deterring example the USB OTG registers).
So, some guesswork may be required from the user.
> There is a set of bits named 'DMAREQ_ID' in register DMAMUX1_CxCR (and DMAMUX2_CxCR) which apparently should specify a peripheral(-action).
Fill that field with a number you find for the desired peripheral-source in Table 118. DMAMUX1: assignment of multiplexer inputs to resources. This field steers the multiplexer which selects the request used for the DMA Stream (channel in case of DMAMUX2/BDMA) which corresponds to given DMAMUX channel.
JW
Oh, I've just realized that ST renumbered the Channels in the BDMA... which is good, as it's consistent with DMAMUX2 Channel numbering now, but now I can go and fix my rant... 😉
JW
