cancel
Showing results for 
Search instead for 
Did you mean: 

About TIM2 in compare mode: I have a few questions about what happens to the output when the timer counter overflows

AMacd.1
Associate III

1. What happens if TIM2_ARR is 0xFFFF? Does overflow occur when timer counter counts past 0xFFFF?

2. What happens to compare output after TIM2 overflows? For example, lets say that the TIM2_CCR1 = 0x7FFF so the output changes state when the counter counts past this value. So what happens to the output when the counter counts past 0xFFFF?

1 ACCEPTED SOLUTION

Accepted Solutions
Piranha
Chief II

I'm not working on STM8, but many peripherals are almost the same and the reference manual seems to confirm that.

  1. Yes, the 0xFFFF value works the same as all other values, except 0.
  2. Again, with 0xFFFF happens the same thing as with 0xFFFE, just one timer tick later.

RM0016 section 17.3.4 doesn't differentiate 0xFFFF from other values:

In up-counting mode, the counter counts from 0 to a user-defined compare value (content of the TIM1_ARR register). It then restarts from 0 and generates a counter overflow event and a UEV if the UDIS bit is 0 in the TIM1_CR1 register.

Probably you should change the way you think about it. You think that it overflows, but actually it never counts past 0xFFFF. Instead it generates an update event the same way as with other ARR values.

View solution in original post

1 REPLY 1
Piranha
Chief II

I'm not working on STM8, but many peripherals are almost the same and the reference manual seems to confirm that.

  1. Yes, the 0xFFFF value works the same as all other values, except 0.
  2. Again, with 0xFFFF happens the same thing as with 0xFFFE, just one timer tick later.

RM0016 section 17.3.4 doesn't differentiate 0xFFFF from other values:

In up-counting mode, the counter counts from 0 to a user-defined compare value (content of the TIM1_ARR register). It then restarts from 0 and generates a counter overflow event and a UEV if the UDIS bit is 0 in the TIM1_CR1 register.

Probably you should change the way you think about it. You think that it overflows, but actually it never counts past 0xFFFF. Instead it generates an update event the same way as with other ARR values.