CCxIF flag in Timerx peripheral

[Legacy member]

Hi,

I'd like to know if execution jumps to the interrupt handler of Timer x only when the CCxIF flag changes state from 0 to 1. What happens if the flag is already set and an event occurs that would have caused the flag to switch from 0 to 1 had the flag been in the 0 state? Would the ISR be called or would it be ignored?

I'm using the STM32G473VCH3 controller. 

Thank you.

[TDK]

It will be called whenever CCxIF=1 and CCxIE=1 (and the relevant interrupts are enabled and of sufficient priority). It is not only called on an edge.

> What happens if the flag is already set and an event occurs that would have caused the flag to switch from 0 to 1 had the flag been in the 0 state?

If the flags were already set, it would have already been called before this event.

[waclawek.jan]

Additionally to what @TDK wrote above, if the event which causes CCxIF to be set is Input Capture (as opposed to Output Compare), TIMx_SR.CCxOF (OverCapture flag) is set, too.

JW

[Legacy member]

@waclawek.jan @TDK, thank you for the replies. Let me explain my application a bit more in detail. Perhaps it would make my problem clearer. I use Tim 5, channels 1 and 2 to detect rising and falling edges respectively, in input capture mode. When a rising edge is detected on channel 1, I use it to trigger Tim 4 in external clock mode, so that I obtain a count of the rising edges. I additionaly am using channel 2 on Tim 8 to get a count of the falling edges. Tim 5 has an interrupt associated with it. In the interrupt handler associated with this interrupt, I check if the capture counter flags are set for the 2 channels and then read the counts of the rising and falling edges from Tim 4 and Tim 8 respectively. Before the read for each channel. I disable the channel and clear the associated CCxIF flag. This where I have a problem. My counter readings for Tim 4 always lag behind Tim 8, when I would have expected them to be the same. Note that I enable the channels 1 and 2 of Tim5 every ms.

I'm not sure why this happens. However, when I don't disable channel 1 of Tim5 at all, my edge counts are the same for rising and falling. This behaviour appeared peculiar to me.

[waclawek.jan]

> When a rising edge is detected on channel 1, I use it to trigger Tim 4 in external clock mode

How? Do you use the internal TRGO-TRGI connection between TIM5 and TIM4? In other words, do you set TIM5_CR2.MMS=0b011?

> I additionaly am using channel 2 on Tim 8 to get a count of the falling edges.

How? Do you have the same input signal which goes to TIM5_CHx (x = 1 or 2, I don't know which one are you using) brought also to some TIM8_CH2 pin?

> Before the read for each channel. I disable the channel and clear the associated CCxIF flag.

You don't need to *clear* the associated CCxIF flag - reading TIMx_CCxR register clears also the respective TIMx_SR.CCxIF, if given channel is set to input capture.

I'm not quite sure what exactly are the consequences of disabling TIM5_CH1 to TRGO (if set as I've said above), but I also don't understand why do you do that - and, what exactly do you mean by "disabling" channel, is it just clearing the respective TIMx_CCER.CCxE bit, or anything else?

JW

[Legacy member]

@waclawek.jan 

> How? Do you use the internal TRGO-TRGI connection between TIM5 and TIM4? In other words, do you set TIM5_CR2.MMS=0b011?

- Yes, this is how I trigger Tim4.

> How? Do you have the same input signal which goes to TIM5_CHx (x = 1 or 2, I don't know which one are you using) brought also to some TIM8_CH2 pin?

- Yes, the same signal is fed to Tim8, channel 2.

>Disabling Channel

- I clear the CCxE bit associated with the channel. 

[waclawek.jan]

@Legacy member ,

the TRGO in this case is a pulse derived from the CC signal which is risen at the same time as the capture happens. Subsequent captures (overcaptures) generate further TRGO pulses, regardless of the state of the TIMx_SR.CCxIF flag.

TRGO may be delayed from the moment of capture, maybe by one or two cycles, but certainly not more, and maybe it's not delayed at all. The interrupt latency is at its absolute minimum 12 cycles, and that's just up to executing the first instruction in the ISR, so in practice, it's one or two (especially if we are talking about Cube/HAL) order of magnitude more. In other words, if disabling channel influences anything, that are subsequent captures, not the one which primarily triggered the interrupt.

Putting it in yet another way, the rising edges happen more often than you can process them in the interrupt, so reconsider that decision. You may want to consider using DMA to transfer the capture times to RAM, if you need all of them.

At any case, there's no need to disable the channel, so just don't do that.

And, as I've explained above, there's also no need to clear the TIMx_SR.CCxIF flag either, as it's cleared by hardware by reading the respective TIMx_CCRx register.

JW