Electronic – Is it really necessary to manually clear the XMEGA timer overflow interrupt flag

atmel-studiocxmega

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?

Best Answer

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.

Related Solutions

Electronic – Could an ARM (ARM7TDMI) Branch instruction take 6 cycles

Are you running code from RAM or from flash? ARM processors that run code from flash often require wait states in at least some circumstances; such processors often include hardware which can eliminate most of the wait states in common code, but such hardware may be as simple as a single-line buffer which allows an access to the same line of flash as the previous access to avoid the wait state. If the branch target is the last word of a flash line, then the flash would require two or three cycles to fetch that word, and two or three cycles to fetch the following word. If one of the cycles is performed concurrently with some other CPU operation, that would leave a three-cycle penalty.

How to detect which timer interrupt called callback when using ASF

The Atmel Studio Framework doesn't clear any of the flags and the underlying code is quite straightforward in that area. The callback routines get setup as follows:

void tc_set_overflow_interrupt_callback(volatile void *tc,
        tc_callback_t callback)
{
#ifdef TCC0
    if ((uintptr_t) tc == (uintptr_t) & TCC0) {
        tc_tcc0_ovf_callback = callback;
    } else
#endif
#ifdef TCC1
    if ((uintptr_t) tc == (uintptr_t) & TCC1) {
        tc_tcc1_ovf_callback = callback;
    } else
#endif
... etc for other timers

And the actual interrupt code is:

ISR(TCC0_OVF_vect)
{
    if (tc_tcc0_ovf_callback) {
        tc_tcc0_ovf_callback();
    }
}
... etc for other timers

The XMEGA is a little different to some processors in that some of the flags get cleared before the interrupt code is called rather than on return. For example the following is the description of the OVFIF flag:

This flag is set either on a TOP (overflow) or BOTTOM (underflow) condition, depending on the WGMODE setting. 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.

One implication of using ASF is that the #ifdef directives above cause all interrupt vectors applicable to a device to be included once you include the timer/counter driver in the project.

But back to your original question as you've found those flags get cleared before the interrupt routine is called. After re-checking the documentation and taking a look at the various timer / interrupt flags before and after an interrupt in a debugger I can't see any way to achieve exactly what you're after. You might have to stick with a seperate callback for each timer that calls the main handler with a parameter. At least the code overhead shouldn't be too great because all the vectors are already included.

Best Answer

Related Solutions

Electronic – Could an ARM (ARM7TDMI) Branch instruction take 6 cycles

How to detect which timer interrupt called callback when using ASF

Related Topic