Has anyone else seen this problem? A Mega48 or Mega88 is running on the internal RC oscillator (8MHz) with timer 2 set up as asynchronous from a 32.768KHz watch crystal, and prescaled so that it gives an overflow interrupt every second. So far so good. Now set up another interrupt on either of the timer 2 compare registers, with the compare register set to 0xFF, i.e. it interrupts about 4ms before the overflow. Still OK. Now, make the compare register interrupt routine write to any of the timer 2 resgiters (such as it would do if it needed to update its own compare register for the next interrupt) - it doesn't have to change the register value, only write to it. Now the overflow interrupt which should have happened 4 milliseconds later fails to happen, and one second of the real-time counter is lost.
A possible clue is that an asynchronous interrupt actually happens one count later than the value in the compare register (or at 0x01, for the overflow interrupt), so when a compare interrupt happens for a value of 0xFF, the counter is already at 0x00, and is presumably priming the logic for the overflow interrupt. Writing to any of the asynchronous registers seems to abort this process. However, a similar problem does not seem to happen between the two compare interrupts - it is only the overflow interrupt which has problems.
Unfortunately this means it isn't possible to have an overflow interrupt reliably counting seconds, and two independent compare interrupts counting shorter intervals, unless the code is fudged to make sure neither of the compare registers ever gets set to 0xFF.
I reported this to Atmel last December, but they said they knew of no such problem. So far I've simply programmed around it by using one of the compare registers as a fixed 1-second interrupt, but now I really need to use both compares in addition to the overflow. Does anyone know of an easy way around this?