# Is it really necessary to manually clear the XMEGA timer overflow interrupt flag?

As some of you may know, Atmel provides a software framework (mainly as part of Atmel Studio) that provides drivers and examples and is updated on a more or less regular basis.

In a recent update they explicitly point out, that it is important to manually clear the overflow interrupt flag in the interrupt callback function.

 // * \subsection xmega_tc_qs_ovf_setup_code Example code
// *
// * Add a callback function that will be executed when the overflow interrupt
// * trigger.
// * \code
static void my_callback(void)
{
// User code to execute when the overflow occurs here

// THIS WAS ADDED IN LAST UPDATE
// Important to clear Interrupt Flag
tc_clear_overflow(&TCC0);
// THIS WAS ADDED IN LAST UPDATE

}
//\endcode


According to the XMEGAA data sheet:

OVFIF is automatically cleared when the corresponding interrupt vector is executed. The flag can also be cleared by writing a one to its bit location.

Is there a scenario/reason where manually clearing the flag may be required?

• sounds like the answer is if you dont interrupt then you need to manually clear it. essentially if/when polling instead of using interrupts. you can simply read the register in the interrupt and somehow display it to see if it was really set. likewise try polling without the interrupt enabled and see if it gets set and if you can clear it. validate the documentation is or isnt correct. – old_timer Jul 26 '16 at 13:28
• That wouldn't be the first case I've seen in Atmel products where an "automatically cleared" interrupt seems to not actually get cleared when the handler fires. – Connor Wolf Oct 25 '16 at 3:47
• @ConnorWolf: Really? Do you remember which controller and interrupt? We work quiet a lot with Atmel controllers and this could be a potential pitfall. – Rev1.0 Oct 25 '16 at 6:18
• @Rev1.0 - An example I'm working with right now: SAM4SD32C - The timer interrupts (TC0_Handler, etc...) are not cleared on entering the ISR unless I explicitly read TC0->TC_SR. Digging deeper, in this case, it's because the interrupt is triggered from the RC compare register match bit, and that is not cleared until you explicitly read TC_SR. IOW, I'm incorrect about the actual cause (it wasn't the ISR bit directly), but the end result is the same: You have to manually clear the ISR cause, if not the ISR flag. – Connor Wolf Nov 2 '16 at 21:44
• Maybe there is an errata? – vicatcu Mar 6 '17 at 0:46