I'm having trouble using the RTC1 COMPARE function to generate an event/interrupt when the processor has been put to sleep using sd_app_evt_wait().
My configuration is as follows:
- Using S110 v7.1.0
- BLE advertising is disabled (to make sleep states more detectable)
- Softdevice initialized at system boot, using the line SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_16000MS_CALIBRATION, 0);
- Prescaler for RTC1 is set to 0xFF, which generates 128Hz ticks.
- Running a custom OS, but making heavy use of softdevice APIs.
The goal is to simply put the processor to sleep and wake up after a specific amount of time by loading the CC[0] and/or [1] register of RTC1 with an appropriate value (in my case, I use 0x80, which should result in a 1Hz interrupt frequency). The RTC code runs exactly as expected without the sd_app_evt_wait() call. The interrupts all go off, and when I inspect the system registers in the debugger (Keil uVision 5.10) I can see that the COUNTER register gets correctly reset by my interrupt handler when the COUNTER value reaches that set in CC[0]. However, when I add the sd_app_evt_wait() call, I see that interrupts are no longer generated by the RTC, and that the COUNTER register in RTC1 goes right past the value set in CC[0].
In fact, what I instead see is that the COUNTER runs up until 0x800 before being reset back to 0 and waking the system up from sleep. More curiously, I found that by simply changing the enum used in SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_16000MS_CALIBRATION, 0); to NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_8000MS_CALIBRATION, I see the counter reset at 0x400 instead, and interrupts trigger twice as frequently. I have gone further and tried some of the other RC-based enums (as I do not have an external 32kHz oscillator on my board), and seemingly the frequency of the interrupts matches the frequency of calibration.
To my understanding, there should be no relationship between the LFCLK source used (as long as it's RC based, anyway) and the COMPARE function of the RTC (other than the obvious small timing inaccuracies, of course).
