8

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?

Rev
  • 10,017
  • 7
  • 40
  • 77
  • 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
  • 1
    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 03:47
  • 1
    @ConnorWolf: Really? Do you remember which controller and interrupt? We work quiet a lot with Atmel controllers and this could be a potential pitfall. – Rev Oct 25 '16 at 06:18
  • 3
    @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 02 '16 at 21:44
  • 1
    Maybe there is an errata? – vicatcu Mar 06 '17 at 00:46
  • if your ISR is running late (other ISRs are using up time) and the interrupt occurs again while you're reprogramming the timer you may get confused .... – Taniwha Nov 01 '17 at 01:39

2 Answers2

1

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.

JimmyB
  • 3,823
  • 2
  • 18
  • 21
1

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.