cancel
Showing results for 
Search instead for 
Did you mean: 

H7: TIM1-triggered DMA and TIM1-ADC-triggered DMA get out of sync at Debug Halt

Kolja Waschk
Associate III

Hi,

in a setup on STM32H725 where TIM1 ETR triggers several DMA activities, I observe an effect while debugging that I would rather like to avoid:

Looking at the NDTR of the three DMA, it seems that one extra ADC run (or at least the related DMA transfers) occurs each time the device is halted for debugging. I do not understand how this can happen.

Basic setup: TIM1 is started by ETR. Two DMA channels capture related register values to circular buffers and are triggered by TIM1 TRG and TIM1 CC4 (at CCR4=1). Combined ADC1+2 is triggered by TIM1 CC3 (at CCR3=89). The ADC results (2x 3x 16 bit) are written to a circular buffer via DMA. All DMA are initialized at the same time. The circular buffers are all of the same size.

All timers are halted during debugging (flags set in DBGMCU->APBxFZ1)

Observation: Normally (without any halt introduced debugger via SWD) the three DMA are perfectly in sync and stay in sync. For example, at each DMA Complete of the ADC channel, all NDTR are reset to the initial value (3072 for ADC where during each cycle 3 words are stored, and 1024 for the other two).

However, each halt using the debugger introduces an extra offset: at DMA Complete of the ADC channel, the other two get behind by +1 element. Now when ADC NDTR is 3072, the others are 1, or after next halt 2, and so on.

It seems that ADC DMA runs for one more time although it should be triggered only by the same events that trigger the others? I could understand a steady offset of 1 the other way round when looking to early (ADC behind others because it finishes later) but not this way, and especially not increasing with each halt??

Thanks for any ideas on this (and if more details are needed on the setup, I'll comment)

Kolja

1 ACCEPTED SOLUTION

Accepted Solutions
Sarra.S
ST Employee

Hello @Kolja Waschk

Ensure that the timers are correctly configured to halt during debugging. The DBG_TIMx_STOP configuration bit in the debug support module should be set for each timer you want to halt. This prevents the timers from generating any further events while the microcontroller is halted.

Also, share the configuration of the PWM channels, especially the idle states, to ensure that no unintended edges are generated during debug transitions.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

4 REPLIES 4
Kolja Waschk
Associate III

... or maybe a DMA request to the other two is somehow "lost" due to the debug event?

Kolja Waschk
Associate III

... maybe the TIM1 PWM CH3 Idle State "set" leads to an extra rising edge at Debug Halt that triggers extra DMA (which is configured to start on TIM1 CC3 "rising edge")?

Sarra.S
ST Employee

Hello @Kolja Waschk

Ensure that the timers are correctly configured to halt during debugging. The DBG_TIMx_STOP configuration bit in the debug support module should be set for each timer you want to halt. This prevents the timers from generating any further events while the microcontroller is halted.

Also, share the configuration of the PWM channels, especially the idle states, to ensure that no unintended edges are generated during debug transitions.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hi, thanks. Indeed, the PWM Idle State "set" instead of "reset" was the culprit, causing an extra rising edge. I didn't realize that a timer held during debug stop becomes "Idle". - Kolja