STM32F4 timer 13 as master for timer 12

[vlpasha]

Posted on January 21, 2016 at 15:38

Can`t get the TIM12 to work in slave mode from TIM13 as master.

/* TIM13 clock is 1us */
TIM13->CNT = 0;
TIM13->PSC = ( TimerBusClock / 1000000U ) - 1U;
TIM13->ARR = 0xFFFFU;
TIM13->CCR1 = 0xFFFFU;
/* TIM12 is slave to TIM13 */
TIM12->SMCR = 0;
TIM12->SMCR |= (TIM_SMCR_TS_1); 
//ITR2 as trigger source
TIM12->SMCR |= (TIM_SMCR_SMS); 
//External clock mode 1
TIM12->ARR = 0xFFFFU; 
//autoreload register
TIM12->CR1 |= (TIM_CR1_CEN);
TIM13->CR1 |= (TIM_CR1_CEN);

I can se that TIM13 is running, the CC1IF flag in SR register is set, but TIM12 remains 0 and not counting. According to RM the TIM12 ITR2 (page 664, table 100) is connected to TIM13_OC, but I can`t find any details on what the ''TIM13_OC'' signal means (is it OC1REF signal, or OC1 signal or something else), and if the TIM13 must be set to a specific output-compare mode to work as a master and clock the slave timer. Anyone tried to link this timers?

[waclawek.jan]

Posted on January 21, 2016 at 16:26

It's the output compare output from the TIM module, i.e. OC1 on Fig. 195 or Fig. 181 in RM0090 rev.11. It means, you have to set an appropriate mode in TIMx_CCMR1.OC1M (try toggle for starter) and enable the output compare in TIMx_CCER.CC1E.

It still does not mean it's mapped it to a physical pin. JW

[waclawek.jan]

Posted on January 21, 2016 at 16:55

Btw., this is a great opportunity to have fun with the 'F4 in a debugger without writing a single line of code.

Run the debugger, connect to target, open the peripheral registers' view. Enable both TIM12 and TIM13 in RCC_APB1ENR. In TIM12, enable counter by setting TIM12_CR1.CEN. Write 2 into TIM12_SMCR.TS (i.e. TRGI is TIM13_OC), write 7 into TIM12_SMS (slave mode is external clock). Chect that TIM12_ARR is at max (0xFFFF). In TIM13, enable output compare output by setting TIM13_CC1E. Now write 4 and 5 consecutively into TIM13_CCMR.OC1M (these are the two force levels). Observe, that TIM12_CNT increments. Enjoy! ;) JW

[vlpasha]

Posted on January 22, 2016 at 08:50Thank You for fast and helpful answer. I was stuck trying to find description in chapters about timers synchronization, and it newer crossed my mind to look in output/compare mode. Now the timers are working.

[henry.dick]

Posted on July 03, 2018 at 16:03

'

Anyone tried to link this timers?'

try this: 

http://stm32duino.com/viewtopic.php?f=18&t=2673

 

[Mikael Isaksson]

Posted on July 03, 2018 at 15:16

I am also trying to do this exact thing. Using Timer 13 as a master to Timer 12. I have tried to get it working for quite some time now, 5 complete rewrites of the code but I can never get it to work properly.

My problem is that my MSB count is out of sync with LSB overflow by a random pretty large margin. (So much so that I doubt the trick to reread the values if it has flipped will work) It makes it really hard to get a 32 bit timestamp using this method. I am certain I have made an error somewhere. I tried looking at the picture with IO registers in the post above to see if something can fix it but to no avail. Unfortunately I have no ability to plug in a debugger.

The chip I'm using is 32F205rb

I realize the thread is old, but I would be eternally grateful if someone have a working example I can try out on my setup. As it stands I am about to implement a solution using an interrupt at LSB overflow instead, does not feel entirely optimal to be honest but that's the way it is.

Kind regards / Mikael

[Edit:]

MSB = Most Significant Byte = Timer 12 CNT

LSB = Least Significant Byte = Timer 13 CNT

[waclawek.jan]

Posted on July 06, 2018 at 17:33

My problem is that my MSB count is out of sync with LSB overflow by a random pretty large margin.

It certainly is - there is some resynchronization between the timers - but I wouldn't call it 'pretty large', and I would be surprised if it would be completely random.

As this is one of the very interesting details ST does not care to publish thus degrading the timer linking facility, I concocted and experiment for DiscoF4, in attachment, where the TIM13->TIM12 are linked and both emit some form of signal on their output channels (details in the source). Running at the default 16MHz HSI clock, they can be easily observed by a LA. Results are (in 1/16MHz units, i.e. system clocks):

ABP1 divider   edges difference

1                       3

2                       3

4                       6

8                     12

16                   24

If I understand this correctly (and chances are that I don't), this should be also the difference between the master clock rollover and the slave clock increment. This means, that if your algorithm reads TIM12->CNT then TIM13->CNT and then TIM12->CNT again, say in the case of APB1 divider being 4, if the two latter readings are less than 6 system clocks apart, there's a chance that TIM13->CNT will be read as the rolled-over value whereas there will be no change in the two readings of TIM12->CNT.

Now, I am not sure whether the AHB-APB bus would enable two reads to be spaced less than 6 system clocks apart, given the APB bus runs at one tick per 4 system clocks... Nevertheless, these figures might perhaps be used as a basis for reading algorithm for such couple: if the value read from TIM13 is lower than the number in the table, a re-read is in place.

Note, that TIM12 and TIM13 are on the same APB bus. This relationship might or might not hold with two timers on two different APB buses even if the divider on buses is the same; with different divider the picture might get even more colorful.

And, as with all experimentally derived facts, they are in no means binding for ST; and they always leave a chance for error by misinterpretation of the observations, so treat it as such.

I'd lóve to hear ST's comments.

JW