How to know if DMA on STM32 is being used or not

Question

I am using the STM32F410CBT's DMA to output a square wave on the PWM peripheral with varying duty cycle. The duty cycle will vary at a button press (through GPIO interrupt). I managed to vary the PWM's duty cycle and verified that the duty cycle is different with each button press through an Oscilloscope. I am using TIM5 configured at 10kHz.

I used the function: HAL_TIM_PWM_Start_DMA(&htim5, TIM_CHANNEL_x, &dutycycle_array[x], 1);, where TIM_CHANNEL_x corresponds to the PWM Channel that I am scoping, dutycycle_array is an array with 101 32-bit elements representing 0% duty cycle up to 100% duty cycle based on its index x.

What is a good indication that the DMA is indeed being used to transfer data from memory to the PWM peripheral without CPU intervention, aside from the fact that I am using a HAL_DMA API, and the fact that there is no code in the while loop? Is there also way to monitor the DMA through Keil (or the processor load through Keil) aside from looking at its registers through the Register Viewer?

Thanks!

Answer 1

This is a rather silly question - you wrote a program designed to use DMA, and the fact that you don't have any other code to perform this should be evidence enough that the DMA engine is doing it... if it is actually happening.

Formally, if you really want to know, you should study the source code of the vendor HAL routines you are calling to configure and start the DMA. The HAL routines are typically compiled from source alongside your custom source code, and they have halfway decent comments, so no great mystery.

I suppose if you really wanted to "prove" it was the DMA engine responsible, you could go and make one tiny edit to the HAL DMA function so that it didn't actually activate the DMA peripheral, but only went through 99% of the motions of preparing it. Do a full clean and rebuild and reflash, and you won't see a progression of data coming out as varied pulse widths. Or you could do something like change the source increment set into the DMA hardware alone, and so cause it to skip every other value.

Or yes, if you want, you could use the debugger and a study of the programmer's manual to go and do a special function register write which would disable the DMA, or kill the clock to it or whatever, after the program had enabled it. Just make sure the program isn't doing operations in a loop which might cause the DMA to be quickly re-enabled again.