I am running into a situation where my boards are waking up from PD0 and then begin to draw additional current (approx 1.5mA in my case). I am not actively using the BLE stack in this case. The stack is initialized bug any active connections are dropped and advertising is shut off.
I have narrowed it down to the controller task being called when the scheduler runs after a wakeup event. At some point after leaving WFI and entering WFI again something is getting set that keeps the XTAL running. I believe that this is the source of my extra current. I can induce this by either allowing the OSC_INT interrupt to wake the system up or by enabling the LPTMR interrupt. In either case the controller task is always woken up. I'm guessing that it's using an RTOS timeout on a resource as part of the main loop. I can prove that no other tasks are waking up when this occurs. I am scoping the XTAL output on PA25.
SDK 2.2.0/bluetooth1.5.4/framework 5.6.4
I have 2 questions:
1. What is the controller task doing that is keeping XTAL active? Are there any race conditions or dependencies on the XTAL32K clock that could cause this? I am using RCO32 as the low power timer source and have run the calibration prior to allowing the device to enter PD. I ask because the timing is unpredictable and not all boards exhibit this behavior (that I can tell).
2. Why does the OSC_INT event keep firing every 10s, even when I have no connections or advertisements active? I am able to mitigate this issue somewhat by disabling LPTMR running and interrupting in PD and by disabling OSC_INT interrupts when in PD. There is very little int the documentation on what this vector is for and what it does/should do.