Unwanted interrupts from unused tmr channels

[John Hite]

Posted on March 20, 2017 at 21:44

Thanks to Clive and JW my timer is starting tick but I am getting interrupts from channels 2-4 and I am only using channel 1. I use the following command sequence so I don't know why CC2-4 are set in the SR.

  TIM_ITConfig(TIM4, TIM_IT_CC2 | TIM_IT_CC3 | TIM_IT_CC4, DISABLE);

  TIM_ITConfig(TIM4, TIM_IT_CC1 | TIM_IT_Update, ENABLE);  TIM_Cmd(TIM4, ENABLE);   TIM_ClearITPendingBit(TIM4, TIM_IT_Update | TIM_IT_CC2 | TIM_IT_CC3 | TIM_IT_CC4);

Thanks,

JH

[waclawek.jan]

Posted on March 20, 2017 at 22:18

The flags in TIMx_SR get set unconditionally, according to the capture/compare/update/whatever events, but they don't fire an interrupt if not enabled in TIMx_DIER. That's the register you want to look at.

JW

PS. One more thing: once you account for TIMx_DIER in the ISR, you may find that there's an interrupt fired with no reason.

The reason is that it takes some time until a TIMx_SR bit clear propagates into the NVIC. The more the APB divider the more that time. You want to clear SR bits as early in the ISR as practical.

[John Hite]

Posted on March 20, 2017 at 22:26

I am disabling them in DIER with:

  TIM_ITConfig(TIM4, TIM_IT_CC2 | TIM_IT_CC3 | TIM_IT_CC4, DISABLE);

It seems CC2-4 are being set in the SR when the counter rolls over. However the one I have configured, CC1 is not set at that time.

Thanks,

jh

[waclawek.jan]

Posted on March 20, 2017 at 22:45

Yes - you have them probably at the default values, i.e. the TIMx_CCRy registers at 0 and the TIMx_CMMRz.CCyS registers at 0 too, which means they are configured for output compare. That TIMx_CCMRz.CCyM is set to 0 and so is the enable bit in TIMx_CCER are irrelevant for the compare event (they are 'only' used to determine the output's state) - the compare event happens when TIMx_CNT == TIMx_CCRy, i.e. at 0, and that sets the respective bit in TIMx_SR.

JW

[Tesla DeLorean · Accepted solution]

Posted on March 20, 2017 at 23:06

The silicon implementation tends to be simplistic, the latches in the SR indicate a 'match' with the CCRx, those bits are then gated with a bit enabling the interrupt (AND), and mixed with other sources (OR), and that signal fed to the TIMx_IRQ pin (internal node).

Thus bits will signal within SR, but not physically cause an interrupt. You can safely ignore the bits in the handler, and you won't get stuck with the interrupt reentering (tail chaining) endlessly.