Confusion on DMAMUX registers in RM0468

[FredS]

     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

 

[JBURB]

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

[FredS]

      Hallo Jacky,

Thank you for your reply and clarification. I think I understand the issues you explained, confiming the chosen method is a matter of taste.

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). I tried the names I found in the 'SFRs' column without success (see my original message), while combinations of naming in the register description didn't work either. Please provide the naming rules for these cases.

And lastly: it remained unclear to me how the entries in the DMAMUX map to the peripherals they are meant to act on. There is a set of bits named 'DMAREQ_ID' in register DMAMUX1_CxCR (and DMAMUX2_CxCR) which apparently should specify a peripheral(-action). From the text I read it isn't clear if this is the specification of the triggering item or the item that will be activated when the MUX-entry is activated. In other words: does the ID points to the source or the destination?

Before writing this help-request I tried several combinations, without a conclusive result. Also on this subject a strong request: please re-write the related section(s) in the Reference Manual to make these issues clear and understandable for non-experienced users that try to apply this hardware.

Thank you in advance for your reply,

have a nice day,

               Fred Schimmel

[waclawek.jan]

> 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

[FredS]

      Dear Jan,

As many times before, thank you for your reply. It is really a gotcha that a firm as ST doesn't manage to produce descriptive and coherent documentation.

I will need some time to translate/interpret the example for the 'USB OTG registers' before I can mark this reply with 'Accept as Solution'.

Have a very nice day,

          Fred Schimmel

 

[JBURB]

Hi Fred,

 

could you tell me if the application note AN5224 Introduction to DMAMUX for STM32 MCUs - Application note helps you?

 

Br,

 

Jacky

[waclawek.jan]

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

[FredS]

Hallo Jan,

It looks like there has changed a lot more than you pointed out: Revision 3 of RM0433 shows chapter 16.4.3 on page 630, while Revision 6 shows chapter 15.6.3 on page 671.

Greetings, Fred

[JBURB]

Hello Fred,

I see you have many versions for the same document why don't you use the Rev 8 of RM0433.

Note that you started the thread with RM0468, related to STM32H72x/73x.

Br,

Jacky

[waclawek.jan]

This was just because above I linked to my DMAMUX/DMA numbering mismatch gotcha, where I mention that in 'H7 BDMA has mismatched numbering to DMAMUX (as do the single-port DMAs in other STM32 with DMAMUX). That was written some time ago, based on the older RM for the only 'H7 which was out there back then, i.e. 'H743 (whence RM0433).

This is a rather surprising change. Would I be in charge of this particular piece of documentation, I would insist on having a remark saying so in the new version of RM0433, in THAT very BDMA chapter (at the beginning of it), so that long-term users are not confused (btw., that change is not mentioned in the changelog either, probably part of "BDMA Major section update", so there's no clarification of that numbering change there either).

Corollary for this particular thread is, that with ST, all things have to be taken with a pinch of salt, as ST is often inconsistent, and even when they fix things, that creates historical inconsistencies.

JW

 

PS. This is not to be taken as criticism (other than call for being more thorough and thoughtful when creating the documentation). I *know*  and do acknowledgte that documenting things is very, very hard work.

PS2. The chapters numbering has moved because the AXI interconnect matrix (AXIM), which was previously a standalone chapter, was demoted to be subchapter of the Memory and bus architecture chapter :)... :)

[waclawek.jan]

> Say, I want to have a DMA action on SPI3-Tx executed, every time an compare event happens on TIM3-CH1:

"Action" (i.e. transfers) are determined only by the addresses in the given DMA Stream's (BDMA's Channel's - again ST"s inconsistent nomenclature) registers. They are entirely independent on the request (trigger) source and routing.

So, in above case

- set up timer, whatever it takes, to generate capture or compare events on TIM3_CH1

- enable DMA request to be output from the timer, by setting TIM3_DIER.CC1DE

- in STM32 without DMAMUX, you'd look at the description of DMA Streams (in dual-port DMA) or Channels (in single-port DMA), to find the particular Stream/Channel into which TIM3_CH1 request is fed (either through an OR, or through a multiplexer - details differ per STM32 family)

- in STM32 with DMAMUX, find the number corresponding to TIM3_CH1 in the DMAMUX1: assignment of multiplexer inputs to resources table, as we discussed above. You can choose any DMA Stream/Channel you want, and in the corresponding DMAMUX Channel's Control register, set this number to the DMAREQ_ID field

- in chosen DMA Stream/Channel, set the Peripheral address register (DMA_SxPAR/BDMA_CPARx) to SPI3 data register's address, and then set up the memory register, number-of-transfer register, the fields of control register including enable. This assuming, SPI3 has been set up properly for transmission previously (i.e. that if you'd write to that SPI3 data register from processor, SPI3 would transmit a frame).

Optionally then you want to enable and handle interrupts from DMA etc.

 

JW