Skip to main content
Explorer
October 29, 2024
Solved

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

  • October 29, 2024
  • 3 replies
  • 1229 views

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

    This topic has been closed for replies.
    Best answer by Sarra.S

    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.

    3 replies

    Explorer
    October 29, 2024

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

    Explorer
    October 29, 2024

    ... 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.SAnswer
    ST Employee
    October 31, 2024

    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.

    Explorer
    October 31, 2024

    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