BlueNRG-2 VTimer wake-up the system every 15 sec

[EYang]

Hello

We're using BlueNRG-2 VTimer to be RTC for wake-up the system when it's in sleeping mode.

when we set the timer 10mins, it still wake-up the the system every 15 sec.

HAL_VTimerStart_ms(0, 600000);

But I don't turn on the other timer such as 1 or 2 or 3

HAL_VTimer_Stop(1);

HAL_VTimer_Stop(2);

HAL_VTimer_Stop(3);

the callback function still return the interrupt source is from timer 2.

HAL_VTimerTimeoutCallback();

is it possible? how do I solve this issue?

it increases whole the power consumption for nothing..

Elliott

[ANath.1]

Hi,

did you find a solution for this? I am facing the same issue

[Winfred LU]

This is expected. It is how the system was implemented.

The system needs to wake-up periodically about every 15 seconds due to some internal mechanisms.

However, the related user callback will trigger only when the timeout that you specified expires.

The application can still leverage the callbacks to have large timeouts.

[ANath.1]

@Winfred LU​ 

The callbacks are triggered according to the large timeouts, however, the MCU wakes from sleep in 15s and increases the power consumption of the system. I have a system where the sleep time is configured for 15 mins but the system returns from SLEEPMODE_WAKETIMER in 15s and does not go into sleep again which means we have 14 mins 45 s of CPU running which consumes ~2mA, reducing the battery life to just 3-4 days. Also, there is no mention of this behaviour in the datasheets(At least I couldn't find some). How can we implement a solution in which the system sleeps for a longer time? In leveraging the large callbacks, we lose on battery life

[Winfred LU]

>but the system returns from SLEEPMODE_WAKETIMER in 15s and does not go into sleep again

Correction needed here. The system needs to wake up at the first 15 second, quickly do some HW chores, go to sleep again, then wait for the next 15 seconds.

The overall power consumption will remain very low, since the the amount of time for these awaking periods compared to sleeping periods is very small (less than 1%, i don't have precise number currently).

>there is no mention of this behaviour in the datasheets(At least I couldn't find some)

Consider it as some hardware limitation. I guess that the Cortex M0 core was originally designed specific to the BLE application only, so this feature was just good enough. In BLE application, the timer to wake up the system does not need to be more than 10.x seconds. With the HW design of this chips, i am not aware of a workaround to get rid of these 15s waking-ups.

[ANath.1]

@Winfred LU​ 

>The system needs to wake up at the first 15 seconds, quickly do some HW chores, go to sleep again, then wait for the next 15 seconds.

This isn't the behavior observed. The system keeps running after waking up from 15s sleep. I can confirm this by running the beacon for 15 mins interval on the battery and observing is its discharge. The battery calculator here supports this observation. I am able to achieve only ~4 days of battery. The current while sleeping for 15 mins should ~1uA, but is only for 15s and the rest 14 m 45 s (885 secs) is around 2mA.

Are there any functions/APIs to confirm that the MCU is going back to sleep after 15s ?

[Winfred LU]

In the case of beaconing, the wake up interval depends on the advertising interval you configured. (The wake up period depends on the content that is about to be advertised.) The maximum possible advertising interval would be 10.24 seconds. The 15 second limitation will not be seen. (So i said it is good enough for BLE applications)

The problem is that it shall enter low power mode after the advertisement is done. My guess would be something wrong with the application code.

[ANath.1]

The application code is such that it advertises at 100 ms for a period of 4 secs and then we set ble to non-discoverable mode and sleep for 15 mins. That where we picture in the sleep. In the 4 secs beaconing time, I don't expect the system to sleep as we have a larger sleep time later on.

4-sec advertisement at 100 ms........15 min sleep........ 4-sec advertisement at 100 ms......15 min sleep.......and so on

[Winfred LU]

In the 4-second advertising periods, for a single interval (100 ms) it may take several ms to advertise, then the device can sleep for the other 9x ms.

Not much compared to the 15-minute periods, but it still counts when we talk about power saving.

In the 15-minute sleeping periods, the system has to wake up at each 15 seconds due to the internal mechanism, then it can go to sleep after that short amount of time.

Recommend to review the application code especially for the 15-minute periods that it shall enter low power (sleep) mode properly.

[ANath.1]

> In the 4-second advertising periods, for a single interval (100 ms) it may take several ms to advertise, then the device can sleep for the other 9x ms.

Not much compared to the 15-minute periods, but it still counts when we talk about power saving

Noted. Will implement accordingly.

> In the 15-minute sleeping periods, the system has to wake up at each 15 seconds due to the internal mechanism, then it can go to sleep after that short amount of time.

Exactly the problem I suspect. How do we ensure that the system is going back to sleep after waking up? I tried adding printfs and led blink, they seem to be executed only once it when wakes up from sleep.