cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 timer sets CC interrupt flags on overflow

sergey239955
Associate III
Posted on January 06, 2012 at 23:59

I found that when output compare registers are loaded with a value that is more than ARR, then on overflow the timer automatically sets compare match interrupt flags.  Has anyone seen it?

#stm32-timer-inerrupt
4 REPLIES 4
Posted on January 07, 2012 at 00:47

I found that when output compare registers are loaded with a value that is more than ARR, then on overflow the timer automatically sets compare match interrupt flags.  Has anyone seen it?

Isn't it documented?

''Bit 1 CC1IF: Capture/Compare 1 interrupt flag

 

If channel CC1 is configured as output:

 

This flag is set by hardware when the counter matches the compare value, with some exception in center-aligned mode (refer to the CMS bits in the TIMx_CR1 register description). It is cleared by software.

 

0: No match.

 

1: The content of the counter TIMx_CNT matches the content of the TIMx_CCR1 register.

 

When the contents of TIMx_CCR1 are greater than the contents of TIMx_ARR, the CC1IF bit goes high on the counter overflow (in upcounting and up/down-counting modes) or underflow (in downcounting mode)

 

If channel CC1 is configured as input:

 

This bit is set by hardware on a capture. It is cleared by software or by reading the TIMx_CCR1 register.

 

0: No input capture occurred

 

1: The counter value has been captured in TIMx_CCR1 register (An edge has been detected on IC1 which matches the selected polarity)''
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
sergey239955
Associate III
Posted on January 09, 2012 at 16:28

Thanks!  Looks like my copy of RM0008 Reference manual is Rev 6 and badly outdated. It doesn't contain the clause about the CCR1 greater than ARR.

Posted on July 24, 2013 at 16:02

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6Vp&d=%2Fa%2F0X0000000bpZ%2FTD5HJApHJXBq5_8AG8sm4hg.VKcAC.1sbXb7ISNUTQg&asPdf=false
Posted on July 24, 2013 at 16:19

This really could have been a new thread.

You should setup the NVIC *before* enabling interrupt sources.

Your timer settings are not correct, and you really want the larger divisor in the Period, having a Period of 1 is problematic.

  TIM_TimeBaseStructure.TIM_Period = 71; // 72 - 1 For 1us - 1 MHz timer

  TIM_TimeBaseStructure.TIM_Prescaler = 0;               // Div 1 (Off - None)

You're not conceivably going to be able to interrupt at 1 us, You can't do much in 72 cycles.

For 1ms

  TIM_TimeBaseStructure.TIM_Period = 1000 - 1; // 1000 ticks at 1 MHz

  TIM_TimeBaseStructure.TIM_Prescaler = 71; // 72 - 1 For 1us - 1 MHz timer

Don't use if-then-else construct in the interrupt handler, you may not arrive there for a singular event.

If you want to measure something, the Period should be large, ideally 65535 (65536-1) so you can timestamp events based on the clocked counter. What are you going to be able to tell if the latched value is 0 or 1?

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..