Clarification about timing inconsistencies on G473CETx LQFP48

[etheory]

Hi there!

I am working on a project using an STM32G473CETx LQFP48 MCU in STM32CubeIDE.

I am using TIM2 to simultaneously:

1.) Generate a PWM output signal using:

• Channel 1 - PWM Generation CH1 - Combined PWM1 mode
• Channel 2 - PWM Generation No Output - Combined PWM 2 mode

2.) Proving a DAC sync using the

• Timer 2 Trigger Out event

3.) Provide a ADC sync using the

• Timer 2 Trigger Out event

4.) Provide a GPIO DMA stream event using

• TIM2_UP

I am initializing everything in this sequence:

HAL_DAC_Start_DMA(&hdac1, DAC_CHANNEL_1, (const uint32_t*)dac_data, 16, DAC_ALIGN_12B_R);

HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc_data, 8*128);

HAL_DMA_Start(&hdma_tim2_up, (uint32_t)mp_gpio_data, (uint32_t)&GPIOC->BSRR, 8);

__HAL_TIM_ENABLE_DMA(&htim2, TIM_DMA_UPDATE);

HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1);

My expectation of this would be that everything starts synchronously in lock step, but instead, what I get is the following:

1.) The TIM2 PWM outputs 1 PWM cycle first

2.) Then the GPIO outputs 1 output

3.) Then the DAC starts

This is weird, as they should all start synchronously at exactly the same time.

What is going on here?

And don't tell me it's HAL. I know HAL sucks, but here it's working just fine.

It sets the TIM start bit which is what it should do, and they should all start running at the same time but they don't.

TIM2 settings:

DAC settings:

DMA Settings:

Also, where in the docs (RM0440) can I find what the timing specifics of the TIM2_UP DMA signal are? There are timing diagrams for Timer 2 Trigger Out Event (listed as Update Event (UEV) but no equivalent for TIMx_UP:

Thanks!

[etheory]

OK Based on this diagram:

I get why I get one PWM pulse before the first other signal, since a UEV is not generated when the timer first starts.

So that makes sense. i.e. it has to go through a full counter cycle (causing one PWM output) before it resets for the first time to generate the first update event, which is then when the first DMA signal is generated.

But that still doesn't explain why TRGO and TIMx_UP signals don't fire simultaneously, which makes the GPIO output and DAC outputs different, with the DAC lagging by 1 Update event.

[etheory]

Is there anyone at ST who could please add some documentation to RM0440 explaining the timing of these signals please? It would be SO useful to know.

[etheory]

Pretty please? Does anyone know the answer here or could please update the documentation since this information seems to be missing? Thanks!

[Hakuki_Riumiya]

probably this

HFSEL bits of DAC_MCR must be set when dac_hclk clock speed is faster than 80 MHz. It
adds an extra delay to the transfer from DAC_DHRx register to DAC_DORx register. 

[etheory]

Thank you SO MUCH @Hakuki_Riumiya for the first decent suggestion as to what the this might be!

I'll try this tonight and report back here if it fixes the issue.

Thank you!

[waclawek.jan]

The DAC triggers DMA request only after it has transferred value from DAC_DHRx to DAC_DORx as a consequence of trigger. It means, that the first trigger - i.e. in your case first timer Update event - transfers the default value of DHR to DOR (i.e. remains at zero), and only after that the first DMA transfer is triggered, which transfers the first datum from memory to DAC_DHR, which then gets output to DAC_DOR only after the second trigger. Read DMA requests subchapter of DAC chapter in RM, this mechanism is described there, together with the solution (i.e. transfer the first value to DAC_DHR before enabling the trigger source i.e. timer, "manually").

Also the DMA-fed-GPIO won't be changed at the same time as the timer Update happens (i.e. the edge on GPIO will have some delay to the edge of the PWM pulse). This is because DMA is not an instantaneous mechanism either - after the trigger, an arbitration process is accomplished inside DMA potentially clashing with other DMA requests of the same or higher priority, then DMA reads the source datum from memory through the bus matrix (potentially clashing with other busmasters such as processor), then it writes that datum again through the bus matrix to GPIO - see AN2548. In other words, there's some minimal lag for all these processes, plus some potential jitter due to clashes with other events. For the fixed portion of delay you can compensate by triggering the DMA intended transfer to GPIO by a suitably shifted CC channel in timer, instead of UPdate.

JW