cancel
Showing results for 
Search instead for 
Did you mean: 

Handling CCxOF flags Input Capture Mode

John Hite
Associate III
Posted on March 21, 2017 at 15:35

STM32F437

In the main code I set ARR to 0xFFFF and PSC to 21000-1, a long count at a leisurely pace. After the timer counts a bit I enable an external event with my function generator. In my ISR experiment I immediately disable the timer ( TIM_Cmd(TIM4, DISABLE);)  and then there is a break point on the next line. At this point I turn off the function generator.

As I would expect it sometime occurs that the CC1OF flag is set as well as the CC1IF flag. Reading about the status register in section 6 of RM0090 CCxOF flags are not described as interrupts. However if I do not clear it my program will re-enter the ISR a second time. So it seems that CC1OF does act like an interrupt as UIF nor any CCxIF flags are set.

I am also curious why TIM_GetITStatus() and TIM_ClearITPendingBit() do not address the CCxOF flags. As one definitely needs to account for the OF bit and clear it.

Thanks,

JH

1 ACCEPTED SOLUTION

Accepted Solutions
Posted on March 22, 2017 at 09:54

Reading about the status register in section 6 of RM0090 CCxOF flags are not described as interrupts. However if I do not clear it my program will re-enter the ISR a second time.

Do an experiment: in the ISR, don't clear the CCxOF, but after having cleared the CCxIF, read back the status register.

Still get extra interrupts?

JW

View solution in original post

2 REPLIES 2
Posted on March 22, 2017 at 09:54

Reading about the status register in section 6 of RM0090 CCxOF flags are not described as interrupts. However if I do not clear it my program will re-enter the ISR a second time.

Do an experiment: in the ISR, don't clear the CCxOF, but after having cleared the CCxIF, read back the status register.

Still get extra interrupts?

JW

Posted on March 22, 2017 at 16:45

Hi JW,

Things are working better than I thought. The problems seem to stem from setting interrupts within the ISR to check on things. I set a breakpoint on or just before the statement:

  cc1ifNow = TIM_GetITStatus(TIM4, TIM_IT_CC1);

and in the register display CC1IF is always zero. But if tally the cc1ifNow variable in the main program with no interrupts it is working correctly.

Also I increment a global each time the ISR is called and display it and there are no excess interrupts.

So the answer to your experiment suggestion is no extra interrupts. But honestly the only time I got overcaptures was when I pausing in the ISR so I check it last before I leave.

The first thing I check is for CC1IF, if true I clear it and UIF because UIF is going to be true each time I get CC1IF as I use:

  TIM_SelectSlaveMode(TIM4, TIM_SlaveMode_Reset);

  TIM_SelectInputTrigger(TIM4, TIM_TS_TI1FP1);

to reset the count on each external event.

If there is a UIF only that means my counter overflowed with no external input. So I keep a tally of those in a 32 bit static var and when I do get an event I shift that tally left 16 places and add it to CCR1 to get the true number of timer clock pulses.

Then I check for overcounts.

Thanks,

JH