I've been tracking a fairly irritating bug, and I finally managed to reproduce it on Dialog sample code. I set up the prox_reporter with CFG_EXT_SLEEP_WAKEUP_RTC so that it will wake up from sleep via the RTC.
When I run the prox_reporter with ARCH_SLEEP_OFF, everything runs just fine. The rtc_interrupt_hdlr trips once every 20 seconds (10 seconds of advertising and 10 seconds before the RTC hits). That's all just ducky.
However, when I run the prox_reporter with ARCH_EXT_SLEEP_ON, after rtc_interrupt_hdlr fires, it then fires *again* 696ms later. That's not good if you're trying to schedule something reliably.
This bug also seems to affect the Timer1 handler as that's what I was tracking down. I'm reporting it on the RTC as it's a *LOT* easier and more obvious to catch this on the RTC handler.
That's too close to the advertising interval to be coincidence. What is the BLE sleep code doing to cause this? And how do I fix this?