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

    // Important to clear Interrupt Flag


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?

  • \$\begingroup\$ 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. \$\endgroup\$
    – old_timer
    Jul 26, 2016 at 13:28
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ Oct 25, 2016 at 3:47
  • 1
    \$\begingroup\$ @ConnorWolf: Really? Do you remember which controller and interrupt? We work quiet a lot with Atmel controllers and this could be a potential pitfall. \$\endgroup\$
    – Rev
    Oct 25, 2016 at 6:18
  • 3
    \$\begingroup\$ @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. \$\endgroup\$ Nov 2, 2016 at 21:44
  • 1
    \$\begingroup\$ Maybe there is an errata? \$\endgroup\$
    – vicatcu
    Mar 6, 2017 at 0:46

2 Answers 2


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

Not sure about the ASF, but there are cases where you need to cancel any pending interrupt. For instance, when (re-)configuring a timer you may want to disable interrupts, modify the timer, and cancel any timer interrupts which may have occurred in the mean time, before re-enabling interrupts.

If you don't even have an overflow ISR you can still poll the OVIF to detect overflow, and reset the flag to arm it for the next overflow.


In general, I always clear interrupt flags just before enabling a given interrupt, in case something set the flag in the past. Seems like cheap insurance.

I'm not aware of any scenario where you need to manually clear the flag unless you aren't using interrupts, and you're looking at the flag with a routine that executes periodically to check for the flag being set.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.