cancel
Showing results for 
Search instead for 
Did you mean: 

Can the BlueNRG-1 be put into SLEEPMODE_WAKETIMER when the BLE stack is idle?

dgardner88
Associate II

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

2 REPLIES 2
dgardner88
Associate II
Posted on November 29, 2017 at 06:19

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?

dgardner88
Associate II
Posted on November 29, 2017 at 18:46

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