cancel
Showing results for 
Search instead for 
Did you mean: 

Confusion on DMAMUX registers in RM0468

FredS
Associate III

     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:Screenshot_Header_DMAMUX1_CxCR.png

on next page:Screenshot_Header_DMAMUX2_CxCR.png

 and on page 691:Screenshot_Header_DMAMUX_RegisterMap.png

At the bottom of page 672 I read:Screenshot_RM0468_Bottom_P672.png

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:Screenshot_Debug_DMAMUX1_DMAMUX_C2CR.png

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

 

12 REPLIES 12

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 🙂... 🙂

FredS
Associate III

Hallo Jacky,

All over sudden it is very busy around this topic.

To answer you question: arriving on page 4 of RM0533, I already had so many questions and uncertainties, I decided to stop reading further for this moment. When things are not clear and I proceed with wrong assumptions/conclusions, the next assumed understanding may appear to be incorrect, causing waste of time and effort.

I have tried to make a sketch to explain what is unclear to me. Maybe I am a bad example of a newbe who tries to use the DMAMUX, in that case I'm sorry for bothering you. Here is my sketch:

Forum_questions_DMAMUX_based_on_RM0533.png

 I assume my questions are clear

 

Further there is another issue that bothers me:

Say, I want to have a DMA action on SPI3-Tx executed, every time an compare event happens on TIM3-CH1:
a) First I define the DMA-action for SPI3-Tx and see it is <DMA1 – Stream0>.
b) In case of a MCU without DMAMUX, I can find a table that shows me the Channel-nr for that DMA-action, with MUX there is no such table.
c) Suppose, I need to choose the channel-nr as x to specify "…req_inx", how do I determine the value ‘x’?
d) Subsequently, how do I specify that ‘channel-nr’ when I want to configure a DMAMUX-request?

e) In the listing of registers in RM0468 I see DMAMUX1_CxCR, where the x stands for that ‘channel-nr’ (if I understand this correctly). BUT: as in the debugger a register 'DMAMUX1_C2CR' appears to be incorrect in the column 'Live Expressions', this syntax is invalid. What name should I use when I want to code a DMAMUX_Request by setting the bits in the register?

Although your answers have not yet resulted in a full understanding, I want to express my gratitude for the efforts you put in this case. Thank you for that,

Fred Schimmel

> 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.

waclawekjan_0-1720548553844.png

 

JW