STM32C0 DMAMUX SYNC example

[Kraal]

Dear community,

I would like to send a char buffer through UART using DMA, but at a precise interval (or delay).

I know how to use the DMA with USART TX, it works flawlessly.
The interesting bit is the delay between the DMA transfers.
I know I can do it with a polling loop, and I know I can do it with a timer and in its interrupt, trig the DMA by enabling the DMA channel.

On the C0 devices (and others), the DMA uses a DMAMUX that has a SYNC feature, which according to the documentation, should provide exactly what I'm looking for.
However, I could not make it work at all.

According to RM0490, table 51 on page 245, the sync input 21 is TIM14 TRGO (by the way, what is TIM14 signal for TRGO ?). So I set the SYNC ID, the number of requests (to anything for the moment, let say 4), rising edge for the sync polarity and set the SE bit (which is redundant with SPOL in my view, since SPOL = 0 will stop the sync).

Has anyone succesfully used the SYNC feature of DMAMUX, to a similar use case ?

Thank you and have a nice day.

[Imen.D]

Hello @Kraal 

Did you follow the DMAMUX configuration and examples provided in this application note: AN5224 Introduction to DMAMUX for STM32 MCUs?

This article helps on how to use DMAMUX: How to use DMAMUX on the STM32 microcontrollers

[Kraal]

Hello @Imen.D 

Thank you for the answer. I have looked at AN5224, but find the information there incomplete.
I will, however, look into the H7 example mentionned on page 9, which seems to do what I want...

In the mean time I used CubeIDE to generate a project for C0 using CubeMX to generate everything. I have yet to make it work.

Have a nice day

[waclawek.jan · Accepted solution]

Hi @Kraal ,

You haven't reported whether you succeeded with the DMAMUX SYNC and I assume you did.

Nevertheless, I took this again as an opportunity to play with the DMAMUX. This code transmits "Hello World...!" in 4 byte chunks once per second. I used the STM32G0B1 Nucleo (which should be similar to the 'C0), and transmitting through UART2 which is connected to the STLink's VCP.

JW

[Kraal]

@waclawek.jan Thank you for taking the time to look into it.

I did not succeed before reading your code, but now it is doing what it should.
I was not very far from success though, and thanks to you Jan I found where the main error was.
In the reference manual for the C011 (RM0490, pages 244 and 245) the tables 50 and 51 listing the trigger inputs and sync inputs are different for tim14_trgo, the trigger is using input 22 (as in the G0 code you sent me) while the sync is using input 21. As soon as I used 22 instead of 21 for the sync input it was working.
I have checked in the G0 RM and both trigger and sync tables are the same.

@Imen.D please update RM0490 table 51 on page 245 so that tim14_trgo is on 22 and not 21 as it is now.

[waclawek.jan]

Hi @Kraal ,

Interesting. I've of course used the 'G0 manual... besides listing the correct number, it also somewhat more correctly lists that signal as TIM14_OC rather than TIM14_TRGO -- neither of these markings is entirely correct, nowhere is it properly explained, and ST just can't get a proper grab on this issue (this is a broader problem of using proper, consistent and coherent marking of inter-module signals they struggle with ever since).

But what's even more intriguing is this related change, dated 11 April 2025 (coincidence with the original post here?), and labelled as "Correct tim14_trgo assignment definition to be aligned with the latest Reference Manual"... so, obviously, internally, a new RM is already available, it's just not there for us, the mere users.

JW

[Kraal]

Ha ! Good catch on the git commit.
On the positive side, it means that there is a team that checks the potential differences between RM and HAL/LL. So the RM does get a side band verification too (if it is not made by an automated tool).

I agree on the naming issues, however it is not always an easy fix...