I am using the RTC in an ordinary way. I have it interrupting every second to maintain a time of day clock. I had 2 issues that I think I have now figured out, but I spent a lot of time doing so. Perhaps documentation could be improved in these areas. Or maybe there is some, but I couldn't find it.
1) The documentation says that because of how the alarm triggers, the alarm register should be one less than the desired count. To me that means if I have a 32768 Hz clock, I should set the alarm to 32767 to get an interrupt once a second. Not so! It seems the correct number is 32766 (2 less than the desired count).
2) The documentation says that the interrupt will stay true for a clock cycle, so the ISR should disable the interrupt and enable it after the interrupt has gone away. Great!! I did that, but found that once in a while, I would miss an RTC alarm interrupt completely. What I finally figured out is that if the RTC Alarm interrupt cannot vector while the request is true, it won't trigger at all. I was running the CPU at 5 Mhz to save power and that meant that I my timer 2 ISR could run longer than the RTC interrupt signal was asserted. Once I figured that out, there are several abvious workarounds. I am now running the RTC alarm interrupt at a higher priority than the timer 2 ISR and it all works fine.
Please confirm that my findings are correct, or give me the correct answers. Please improve the documentation.
According to the reference manual, the RTC compare value should only be set to one less than the desired value when the auto-reset mode is enabled in the RTC. Are you using the auto-reset feature? Can you also please let me know which clock source you are using and how you are determining the interrupt interval?
Regarding issue 2, I don't think this issue is with the RTC. When you have two resources with the same priority level requesting for an interrupt service, the core can only service one resource, and the other one needs to wait. In this case, the core is busy serving the timer2 ISR and in order for the RTC interrupt to use the core, it has to be set at a higher interrupt priority than timer2, or wait until timer2 ISR is done. In this case, the RTC interrupt signal is asserted for a period shorter than the timer2 ISR, therefore the RTC ISR needs to be set at a higher priority to avoid missing interrupt request from RTC. This is an expected behavior.
Its output is connected to XTL3 and the XTL4 pin is open. I have has similar results on circuits using 10PPM crystal connected as directed. I have compared it to a GPS 1PPS and to computer clocks that are regularly synchronized to a standard. I each case, the results are within spec if I set the Alarm registers to 32766 which is 2 less than 32768 but off by way to much if I set it to 32767 which is 1 less that the desired counts per interrupt..
For the second part, I was not surprised that the interrupt was delayed, but that it was totally lost. I think that should be documented.
Regarding the oscillator, have you verified the actual frequency of the TCXO on the board? There might be some amount of variation of the oscillator itself, and I would like to rule out this being the cause.
Regarding the interrupt, the reason it is lost is likely because this interrupt is asserted for a time shorter than the timer2 ISR, and by the time the timer2 ISR finishes, the interrupt flag is already de-asserted, and the interrupt vector won't trigger this interrupt handler. Note that this interrupt will only be asserted for one clock cycle, which is documented in the reference manual.
Thank you for testing this and bringing this into our attention. I have made a note about this and will test and verify this issue.