cancel
Showing results for 
Search instead for 
Did you mean: 

Configuring timers on STM32F103C8T6 for 32-bit resolution input capture

wanders
Associate

What I would like to do is the following:

1) Take a pair of the STM32F103C8T6's 16-bit timers and link them into a 32-bit timer (I'm pretty sure there's an app note somewhere that describes this)

2) Then, configure that 32-bit timer for input capture (it looks like this may require shorting the input trigger GPIOs together)

3) Then, of course, configure the timer to call an IRQ routine.

I'm not too worried about over-capture. I'm trying to capture events that may happen several milliseconds apart with microsecond accuracy, so the Cortex M3 should easily be able to keep up.

Questions:

1) Is this easiy done?

2) What are the issues, if any, regarding simultaneous input capture on linked timer pairs?

I'm a bit surprised that a 32-bit MCU doesn't have a 32-bit timer or two (I know that other STM32F's do, but why not the STM32F103?)

2 REPLIES 2

> 1) Is this easiy done?

Yes. Set TRGO of master to update, select proper TRGI at slave and set its mode to external counter.

> 2) What are the issues

The main issue is, that it takes some cycles to propagate master's update, through the TRGO->TRGI link, to slave's counter, it means, slave will increment when master would already have counted up several times (i.e. you would see 0x0000FFFF 0x00000000 0x00000001 0x00000002 0x00010003 0x00010004 on the "cumulated counter" would the delay be 3 timer cycles). This delay is *not* documented so you would need to determine it experimentally. Also, I wouldn't use timers on different APBs, where this delay may be different from that when the timers are on the same APB.

Other than that, I don't see why capture wouldn't work. You would need to connect the pins as you've said.

JW

JW,

Thanks for the insight! I sincerely appreciate your response.

You wrote:

> The main issue is, that it takes some cycles to propagate master's update, through the TRGO->TRGI link...

I assume that these cycles are APB cycles (i.e. SYSCLK divided by AHB and APB prescalers, with a max rate of 36MHz). Too bad there's not some interlock to eliminate this window. Too bad there are not a couple of 32-bit timers...

I'm hoping that I can write code to detect a possible latency error when reading a channel's capture register. But since I'm going to prescale the LSW timer to be triggered only once a usec, I'm hoping that this latency issue isn't really a practical problem. This is for a gaming device, not health care or vehicle control.

Thanks again!