2017-11-27 10:28 PM
Posted on November 28, 2017 at 07:28
I'm measuring ~1.7mA @ 3V in SLEEPMODE_CPU_HALT and SLEEPMODE_WAKETIMER modes.
This is with all peripherals disabled except NVM and SYS_CONTROL.
The datasheet indicates:
Sleep mode: 32 kHz XO ON (24 KB retention RAM) ------- 0.9 uA typ
Active mode: CPU, Flash and RAM on ------- 1.9 mA typ
I expected halting the CPU to result in a much lower current draw than 'Active mode', however it seems to be pretty much the same and to be the same as SLEEPMODE_WAKETIMER.
I measure an expected <20 uA in SLEEPMODE_NOTIMER.
Appreciate any help,
-David
2017-11-28 09:19 PM
It looks like calling BlueNRG_Sleep(SLEEPMODE_WAKETIMER, 0, 0), when the BLE stack is idle, does not have the expected result. The BLE stack reports it is okay with SLEEPMODE_NOTIMER when that function is called, and the allowed sleep state is determined to be
SLEEPMODE_WAKETIMER, but the measured current draw is higher than expected for SLEEPMODE_WAKETIMER.
If the BLE stack is idle and I call the command above, then the current draw is ~1.7mA.
If the BLE stack is advertising or connected and I call the command above, then the current draw is the expected value according to the current calculator. (~150uA for a 30ms conn interval)
Can the BlueNRG-1 be put into the
SLEEPMODE_WAKETIMER when the BLE stack is idle?
2017-11-29 09:46 AM
After some more experimentation, it looks like there is a requirement that a HAL virtual timer is set before BlueNRG_Sleep(
SLEEPMODE_WAKETIMER, ...) is called and that timer can either be set by the app or the BLE stack. Otherwise the mcu looks like it gets into a state similar to CPU halt.
I'm not certain where this logic is. There's nothing in 'sleep.c' that seems to check for a running timer, and the code seems to follow the same execution path whether a timer is set or not.
Final current measurements without the BLE stack running, @ 3V:
*
SLEEPMODE_NOTIMER - 0.35 uA
* SLEEPMODE_WAKETIMER (2000ms wakeup period) - 2.5 uA
* SLEEPMODE_CPU_HALT - 1.53 mA