cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F103 32bit resolution capture sync problem

Oblomkov.Ilya
Associate

Hi,

In my project two 16 bit timers chained together to achieve 32bit capture resolution. TIM3 as master timer and TIM4 as slave timer clocked by TIM3 overflow event (TIM4 works in external clock mode 1). Capture signal is connected to both timers input (CH2 for TIM3 and CH1 for TIM4). Master timer running at 36Mhz (72Mhz / 2).

Captured data processed in TIM3(master) capture interrupt.

Interrupt looks like:

uint32_t period_ticks = 0;
uint16_t ccr_msb = TIM4.CCR1;
uint16_t ccr_lsb = TIM3.CCR2;
uint32_t ticks = (ccr_msb<<16) + ccr_lsb;
period_ticks = ticks - pre_tick_count;
pre_tick_count = ticks; // pre_tick_count is static
 
 

Most time this code works as expected, but issue occurs when ccr_lsb (master timer captured value) == 0, than ccr_msb (slave timer captured value) is one less than expected, and period_ticks become 65535 less than expected. Looks like some sync problem when capture event at the same time with slave timer overflow event. Ugly workaround like

if (ccr_lsb == 0) ccr_msb++;

helps solve this issue. Is there a right way to configure timers to work in 32bit capture mode without such workarounds.

1 ACCEPTED SOLUTION

Accepted Solutions

Yes, there's a delay in the master-slave connection, and ST does not specify it. I guess, would the timers be on different APB buses and would these buses run on different frequencies, the delay might be different than 1. But this is not your case.

So you either go with your experimentally determined value, or don't use this method. Clive proposed a nice workaround for this problem, see "Posted on May 19, 2017 at 04:09" in https://community.st.com/s/question/0D50X00009Xkh7YSAR/cube32mx-input-capture-overflow-detection .

JW

View solution in original post

2 REPLIES 2

Yes, there's a delay in the master-slave connection, and ST does not specify it. I guess, would the timers be on different APB buses and would these buses run on different frequencies, the delay might be different than 1. But this is not your case.

So you either go with your experimentally determined value, or don't use this method. Clive proposed a nice workaround for this problem, see "Posted on May 19, 2017 at 04:09" in https://community.st.com/s/question/0D50X00009Xkh7YSAR/cube32mx-input-capture-overflow-detection .

JW

Thanks! Looks like I need to experimentally determine delay value for timer sync signal.