STM32G4 TIM1 CC (Capture/Compare) Interrupt happened immediately when it is enabled. How to prevent this from happening?

[JY.1]

Hi,

I am using STM32G474 Nucleo board and try to use TIM1_CC_IRQHandler. I am using TIM1_UP_TIM16_IRQHandler to check certain conditions and then I'll enable the CC1IE bit in TIM1->DIER register.

I configured TIM1 as Center-aligned PWM mode.

However, I noticed that right after enabling this bit, CC1IF will already be set in TIM1->SR register and thus NVIC of TIM1_CC_IRQHandler is already in Pending state. So I have sporadic interrupt trigger my TIM1_CC_IRQHandler when Capture/Compare did not actually happen.

How can I prevent this from happening and why I have this CC1IF flag set immediately after I enable CC1IE?

Update:

So I tried to clear the CC1IF flag "before" I enable CC1IE, (although that the flag did NOT show to be set in the debugger) and this sporadic interrupt did not happen. However, I did not see interrupt generated when the very next Capture/Compare happens, instead seeing the interrupt happens at the second next Capture/Compare. How can we explain this phenomenon. Also, does this mean that there is some delay for enabling the CC1IE bit so that the first next Capture/Compare was missed?

Update 2:

I noticed that compare only happens at a certain direction when CNT matches CCR1, but not the other direction. Again, my TIM1 is set to be Center-aligned and up/down counting. Is there anywhere that mentioned this kind of behavior of capture condition?

----------------

Resolved:

So I figured out that there are two steps to solve my problem. First is that I need to clear CCxIF flag before I enable CCxIE so that it won't be set immediately after I enable it. Second is that CMS in TIM1->CR1 should be set properly to configure when to generate the interrupt flag.

Thanks!

JY

[waclawek.jan]

The interrupt enable bit (CCxIE) does not prevent the CCxF flag to be set; i.e. it's not *before* the CCxF latch, but *after* that latch on the route to NVIC.

If you leave CCx as output compare (which is the default state), there's a CC event upon each match (which if you leave CCRx at default 0, is when counter overflows and reaches 0). So, one possible solution might be to set the given channel to Capture in CCMRx, while not being enabled in CCER.

JW

[Uwe Bonnes]

Check what capture condition you set.

[JY.1]

Update:

So I tried to clear the CC1IF flag "before" I enable CC1IE, (although that the flag did NOT show to be set in the debugger) and this sporadic interrupt did not happen. However, I did not see interrupt generated when the very next Capture/Compare happens, instead seeing the interrupt happens at the second next Capture/Compare. How can we explain this phenomenon. Also, does this mean that there is some delay for enabling the CC1IE bit so that the first next Capture/Compare was missed?

[JY.1]

Update 2:

I noticed that compare only happens at a certain direction when CNT matches CCR1, but not the other direction. Again, my TIM1 is set to be Center-aligned and up/down counting. Is there anywhere that mentioned this kind of behavior of capture condition?

[JY.1 · Accepted solution]

Resolved:

Thanks for the heads-up above.

So I figured out that there are two steps to solve my problem. First is that I need to clear CCxIF flag before I enable CCxIE so that it won't be set immediately after I enable it. Second is that CMS in TIM1->CR1 should be set properly to configure when to generate the interrupt flag.