> But there is one problem. When the timer overflows, how do I know that the counter restarted.
Enable DTMRn[ORRI] and it will generate an interrupt when it overflows. That interrupt routine then increments an "upper" 32-bit counter, so now you have a 64-bit timebase. You now have to be VERY careful when reading the counter (DTCnn) to see if you read it just before or just after the overflow interrupt. You need a robust mix of disabling interrupts, reading DTERn[REF], reading the upper counter, DTCNn and DTERn[REF] again, then enabling interrupts. If DTERn[REF] changed while reading the other values then you don't know if you had the before-or-after increment value of DTCNn (although checking to see if it is greater or smaller than 0x80000000 is an obvious check), so just repeat the cycle.
You can have it generate both Capture and Overflow interrupts. You could also use one of the other three DMA timers if that is more convenient.
If you're not using interrupts you can POLL the register for overflows (at a rate faster than the wrap time, which is a minimum of 53 seconds). If DTCNn is LESS than it was on the previous read then it has overflowed, so increment the upper softwarecounter.
> I know that I can use GPT#3 for this purpose but that is 16-bit timer only and it overflows too quickly.
The fastest you can run a DMA Timer is 80MHz. It would then overflow in 53.7 seconds. Adding another 16-bit timer (GPT3) to the end of that would mean that timer overflows in 3518437 seconds, or 977 hours or 40 days. How is that "too quickly"? How is that "too quickly" for your software to watch it and notice when it has gone from 0xFFFF to 0x0000? You could even get that timer to generate an interrupt (every 40 days) and then count that overflow in software.
But you only need software overflow detection on the DMA Timer. 64 bits at 80MHz will count for 7,311 YEARS.
Tom
