STM32G4: trigger one DMA stream by both capture & overflow/update timer events?

[Anand_M]

I am trying to capture timestamp values using STM32G474RE.

Requirement

I need to route:

• COMP1 output -> Timer input capture

• COMP2 output -> Timer input capture

On each comparator edge, the timer should capture the current counter value and transfer it to RAM using DMA.

In addition to edge captures, I also want the same timestamp stream/buffer to receive an entry whenever the timer overflows/updates.

Example desired stream: (Consider its a 8bit Timer)

240, 244, 248, 254, overflow_marker_or_last_CCR, 6, 8, 12

or during no-edge periods:

200, 200, 200, 200

if the update DMA reads the last captured CCRx value.

STM32F072 behavior

On STM32F072, I was able to achieve similar behavior by enabling both DMA request bits:

TIMx->DIER |= TIM_DIER_CC1DE | TIM_DIER_UDE;

This allowed the DMA stream to be triggered by both:

• capture/compare event

• update/overflow event

Issue on STM32G474RE

On STM32G474RE, DMA routing goes through DMAMUX. For example:

• TIM2_CH1 has one DMAMUX request ID

• TIM2_UP has another DMAMUX request ID

So one DMA channel appears to be able to select either TIM2_CH1 or TIM2_UP, but not both.

Questions

1. Is there any timer on STM32G474RE, such as TIM1, TIM2, TIM3, TIM4, TIM5, TIM8, or TIM20, that can merge CCx and UP DMA requests into one DMA stream?

2. Can TIMx_DCR / TIMx_DMAR DMA burst mode help here, or does it still require one selected DMAMUX request source?

3. Can DMAMUX request generator or synchronization be used to OR/combine TIMx_CHx and TIMx_UP events?

4. Can HRTIM capture both comparator external events and timer update events into the same capture register and then DMA that register? (Note: with HRTIM it is possible but i need to run the timer at 2.4MHz so i can't use the HRTIM)

5. If this is not possible in hardware, is the recommended method to use capture DMA plus update interrupt, or two separate DMA channels?

Can someone confirm whether STM32G474RE supports this single-DMA-stream behavior, or whether the STM32F072-style method is no longer possible because of DMAMUX?

Thanks.

[waclawek.jan]

Without giving it too much thinking: no, you can't do this in 'G4 and you will need to invent something else.

What about utilizing the potentially very long period of the 32-bit timers (TIM2, TIM5)?

JW

[Anand_M]

@waclawek.jan 

Thanks for your suggestions:)

I had also considered using TIM2/TIM5 32-bit timers.

The main concern is throughput. With a 32-bit timer, each edge timestamp becomes 4 bytes instead of 1 or 2 bytes, so the USB/DMA data rate increases significantly. Since I am running the timer at 2.4 MHz, the 32-bit counter overflow would occur only after around 29 minutes, so overflow itself is not frequent, but I would still need to track it separately in software.

The bigger issue is when there is no CC-line toggle for some time. In that case, no capture event occurs, so the DMA half/full complete callbacks will not trigger. I would then need some separate mechanism to flush or mark the DMA stream during idle periods. That may create timestamp synchronization issues between real edge captures and software-generated idle/overflow markers.

So using a 32-bit timer solves the counter overflow problem, but it does not fully solve the gap/idle tracking problem in the DMA stream.

[waclawek.jan]

If you are willing to experiment, try this: set up a separate DMA for CC and for Update. Set the Update DMA to write circularly a single value, corresponding to TIMx_EGR_CCxG for the given CC channel, into TIMx_EGR. That should trigger a transfer in the CC channel shortly after the Update, without generating Capture itself.

I'm not sure this will work as expected, so it's something to try.

JW

[Gyessine]

Hello @Anand_M 

Could you use two DMA channels instead: one for CC events and one for update events, then merge the results in software into a common buffer that grows with each DMA event?
I think this would be the simplest solution.

If there is any constraint preventing that, I suggest Jan’s solution. However, I think that it would only generate one CC event after each overflow, so it would not provide a truly continuous timestamp stream.

Is using the STM32G474 mandatory in your case? Also, have you considered other STM32 products?
BR
Gyessine

[waclawek.jan]

> Is using the STM32G474 mandatory in your case? Also, have you considered other STM32 products?

Good point. The 'F3 is similarly capable than the 'G4, while having similar DMA arrangement to the 'F0, without DMAMUX.

JW

[Anand_M]

@waclawek.jan  @Gyessine 

Thanks for your suggestions. I’ll go through the STM32F3 features once to check whether they match our requirements.

In the meantime, I have come up with a couple of ideas to resolve this using the STM32G4 series. These are currently in the testing phase, and I’ll share the experiment results soon.