timer DMA GPIO input capture with constant frequency

[EvgenS Po]

Posted on May 09, 2018 at 08:37

Hello! I need to capture signals on inputs with constant frequency for further investigation. I use the following scheme: set timer frequency needed with update DMA request and capture size for DMA, then get data from input pins via DMA. The capture itself works. The problem is DMA capture inaccuracy, it seems DMA capture frequency floats and is not constant which results in input signal wrong capture. For exapmle, timer update frequency (capture frequency) is 100 kHz, input is10 kHz PWM signal with 50 % duty cycle; capture is 10,5 kHz PWM with 40 % - 55 % duty cycle. The more capturing frequency, the more capture inaccuracy. If timer update frequency is 1 MHz, input is10 kHz PWM signal with 50 % duty cycle; capture is 10,5 - 12,3 kHz PWM with 40 % - 55 % duty cycle. Please, see attached picture. I tried to sleep CPU while capturing, the result is the same.

What could be done to make capturing precise and stable?

#timer-update-dma-gpio Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on May 09, 2018 at 10:48

Salient details here would be the specific STM32 parts being used, the clocks, and prescaler/period settings of the timers.

The periodicity of TIM driven DMA should be pretty consistent.

[T J]

Posted on May 09, 2018 at 13:20

it may be that your program is not structured quite right.

I found using input capture on either edge, captures a fast running clock.

the trick is never reset the TimerValue, just use the relative time between interrupts.

but when the pulse is almost instant at 0.00001% duty cycle, you will miss an interrupt,

so the DMA is the better path.

not sure if you ask the DMA to save the timer value,:( never tried it )

then the DMA could save all 32TimerBits, if you need fine, high resolution

which chip is it ?

which reference manual are you looking in ?

[EvgenS Po]

Posted on May 09, 2018 at 13:50

MCU is stm32f042k6t6t, system clock is 48 MHz PLL sourced by HSI/2 clock. DMA request timer is TIM3, PSC = 23, ARR = 20. During capture cpu sleeps (WFI command), no processing executed, only DMA and TIM3 are active.

'The periodicity of TIM driven DMA should be pretty consistent.' How can one achieve that? Does external crystal add stability?

[waclawek.jan]

Posted on May 09, 2018 at 16:27

system clock is 48 MHz [...] PSC = 23, ARR = 20

That does not sound like 100kHz nor 1MHz.

JW

[EvgenS Po]

Posted on May 09, 2018 at 17:08

48000000/(PSC+1)/ARR=48000000/24/20=100000.

Frequency itself does not matter in that case. Whatever it is, it seems DMA capture happens with different periods.

[Jan Waclawek]

Posted on May 09, 2018 at 18:02

Except that it's (ARR+1) (the counter counts from 0 to ARR, inclusive).

Whatever it is, it seems DMA capture happens with different periods.

Then you have error in your code.

Turn the DMA around and output to GPIO so that it forms an alternating pattern.

JW

[EvgenS Po]

Posted on May 10, 2018 at 08:40

We are talking about different things.

Let me explain the situation more clearly.

I need to capture GPIOx->IDR (only 0-7 bits) value with certain sample rate.

I use TIM3 set to certain update frequency to request DMA to capture GPIOx->IDR value.Some PWM signals are applied to GPIO pins and captured with sample rate.To test the system PWM signals have 50 % duty cycle and low frequency 10 kHz.TIM3 is set to 100 kHz update frequency, well, 95 kHz, you are right (ARR+1), thank you for that.

During capturing cpu sleeps, only DMA and TIM3 are active.

As a result I see captured waveform with duty cycle not 50 % as expected, pulses differs from each other, that is, one pulse has 44 % duty cycle, the other - 52,3 %, another - 48 % among the same waveform. It is seen in attached picture in question. Sample frequency is 10 times faster than input signal, it is fast enough to represent original one. Maybe not? Well, let it be faster. Set TIM3 to 1 MHz update frequency. The result is even worse, than it was before: pulses have duty cycle from 44 to 66 %. So, pulses sometimes are wider or more narrow and this 'walking part' sometimes is added to or substructed from the whole period, making frequency of captured signal not uniform.

So the actual frequency, 95 or 100 kHz, is not so important especially when we are talking about captured waveform's duty cycle. The wrong behaviour / error is somewhere else. But where? I think this situation is possible if DMA capture occures at not equal moments of time, for example at 0, 10, 21, 29, 40, 52, 61, 68 us and so on.

It is a strange situation. What can cause it?

[henry.dick]

Posted on May 10, 2018 at 14:19

From your description it is not clear if you are sampling the in out or capturing the input. 

And what you were trying to show with that picture.

[waclawek.jan]

Posted on May 10, 2018 at 12:58

It is a strange situation. What can cause it?

As I've said, some error in your program - either a plain bug, or some misunderstanding of how things work.

And, as I've said, turn the DMA around and instead of inputting, output alternating data to a GPIO and observe those. That would give you information of how regularly or irregularly the DMA works.

JW