STM32 timer misses count in Input Capture mode

[Mechatronz]

Posted on June 29, 2018 at 10:16

Hi everyone. I am using STM32F303RE and STM32L011 nucleo boards as a part of my experiment. I used STM32F303RE to generate PWM signal (in Interrupt mode) for 1MHz.

Clock Source - PLLCLK (8Mhz * 9 = 72 MHz).

Timer Period = 71

PWM pulse = 35 (for 50% duty cycle)

I used picoscope to measure the frequency. You can see the image below.

Now, i set up the STM32L011 in input capture mode (interrupt mode) to capture this 1 MHz signal. It has 32MHz clock source. The input signal is divided by 8 ( sConfigIC.ICPrescaler = TIM_ICPSC_DIV8;)

In Interrupt mode, i used CCR register to get the captures done. I read it through UART in serial plot.

As you can see, the timer misses a count. I don't know the problem behind this but this always happens. The timer always misses a count. I tested with different signals but got the same result. Even tried PWM with STM32L011 and captured in another controller, but the result is the same.

Here is the capture_flag_function that i use to get the values

void capture_flag_function (void)

{ switch(capture_flag) { case 1: compare_value = htim2.Instance->CCR1; break; case 2: capture_new = htim2.Instance->CCR1; CAPTURE_sm = BUFF_FULL; break; default: break; } }

by comparing compare_value and capture_new, i obtain the count value.

if(capture_new > compare_value)

count_new = capture_new - compare_value; if(capture_new < compare_value) count_new = 65536 - compare_value + capture_new;

Does anyone have an idea of the problem I am facing? Or can you give me suggestions if I am doing something wrong. Thank you.

#count #stm32f303 #stm32-timer-counter #timer-interrupts #frequency-detection #stm32l0-timer #stm32f303-timer Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Mechatronz]

Posted on July 03, 2018 at 11:58

I am running TIM6 as the base timer. The source clock is 72 MHz and it counts for a duration of 100µs and provides an interrupt. Inside the interrupt, I read the TIM2 counts (set to maximum of 65535). At the end of the interrupt, I reset the count of TIM2 to 0, so that no overflow happens. Still, I am getting a count of 44-46. Basically, its 440-460 kHz while the actual frequency is 451 kHz.

I tried the same thing without resetting the TIM2. Similar thing happens. There was no math error and no jitters. The source signal has a noise of less than 20 Hz and the signal is stable at 451 kHz.

[Dan Mackie]

Posted on July 05, 2018 at 15:44

I don't think using the debugger is a good idea at all when you are doing the kind of measurement you are doing.  It is fine to use it to establish the code, but when testing performance, prove your code and the hardware without any use of the debugger.  Run for long enough that you establish solid rates, and then output your evidence as required, but not using the debugger.  Further, if you are looking for an interrupt every 1 usec, have you looked at the total instruction time of your interrupt handler, or as has been said earlier, guaranteed that no other interrupts are happening?

[Mechatronz]

Posted on July 05, 2018 at 15:52

Thank you for your response. I used debugger only as a last resort. If you just scan through the whole page, I would have mentioned about obtaining values through UART and not debugger. Also, I am using STM studio which is a run-time monitor I believe. 

To answer your question, my interrupt handler takes less than 500nSec.

[Dan Mackie]

Posted on July 05, 2018 at 19:03

My original statement should be revised to include not using the debugger or any I/O except what you are measuring, and to measure into memory only.  After you have run long enough in this mode to have seen your problem twice in the previous setup, if you have not seen the problem, then you have isolated the issue - it is the debugger, or serial I/O that is giving you the skew.

[Dan Mackie]

Posted on July 06, 2018 at 16:23

We are assuming that the generated signal is 100% perfect, and the problem is in the counting.  That assumption might be wrong.  Further, interrupt skew can certainly cause problems. It is not expensive to use a different faster machine as the source of the input data stream, (say the F429i at 216 Mhz, or the F7xx, you have options) and see what happens to your figures using the same counting machine.  You might also do the same with the input machine - use a faster machine, and see what happens to your accuracy.  Having certainty on all the interrupt sources also seems important to me.  You can use a vector table so that all interrupts are trapped and identified.