Wake from Bluetooth event

[josuah]

Imported from brilliantlabsAR/monocle-micropython#282

The nRF52832 supports a "System ON" mode where the MCU is expected to only draw 2.0µA of power, where a Bluetooth event is expected to wake-up the device.

https://devzone.nordicsemi.com/f/nordic-q-a/86697/system-on-mode-bluetooth-event-wakeup-nrf52832

This would allow to keep the Monocle (or Frame) sleeping, until the phone decides to send something to it.
Common use-case: navigation, notifications, messaging...

https://discord.com/channels/963222352534048818/1237744387094483045
https://discord.com/channels/963222352534048818/1177192379493662792/1177301538490818640
https://discord.com/channels/963222352534048818/1216429459079692370/1216686766522761267
https://discord.com/channels/963222352534048818/1237744387094483045/1237988595378290690

[OkGoDoIt]

+1
Add my vote to prioritize this, it would be super useful for common use cases

[siliconwitch]

Very useful feature. I'll add it to the backlog and try to figure out a timeline for it

[Dennisjoch]

I've reviewed the firmware. Setting NRF_POWER->SYSTEMOFF = 1; only allows wake-up via the IMU_INTERRUPT_PIN, as shown here:

if (enable_imu_wakeup)
{
    nrf_gpio_cfg_sense_input(IMU_INTERRUPT_PIN,
                             NRF_GPIO_PIN_NOPULL,
                             NRF_GPIO_PIN_SENSE_LOW);
}

This means it wouldn’t work with Bluetooth for wake-up. However, instead of setting SYSTEMOFF = 1, you could keep the system in a low-power state, which would theoretically require 2.0µA of current. In this case, you could implement periodic Bluetooth scanning, where Bluetooth is turned on at intervals to check for any signals.

This is possible, but it raises the question of how the battery life would be affected. Additionally, using an interval-based approach would require waking up the CPU periodically, which would also consume additional power. I plan to test this when my nRF52840 DK arrives, but I won't have exact battery life measurements until then.

If I’ve misunderstood something, please correct me.

[josuah]

I've reviewed the firmware. [...] This means it wouldn’t work with Bluetooth for wake-up.

I think you are right.

If I’ve misunderstood something, please correct me.

Some interesting bit of the SoftDevice API here:
https://docs.nordicsemi.com/bundle/sds_s132/page/SDS/s1xx/sd_mgr/power_mgmt.html

• (optional) Call sd_power_mode_set() to configure the power mode. The default is LOWPRW (lowest power) instead of CONSTLAT (lowest latency):
  https://github.com/brilliantlabsAR/frame-codebase/blob/main/libraries/softdevice/include/nrf_soc.h#L520

• Call sd_app_evt_wait(void) to trigger a Bluetooth-aware sleep: a sleep mode that will still let the SoftDevice wake-up on radio event to process Bluetooth events:
  https://github.com/brilliantlabsAR/frame-codebase/blob/main/libraries/softdevice/include/nrf_soc.h#L748

You can also find the general mechanism explained here:

https://infocenter.nordicsemi.com/pdf/S132_SDS_v7.1.pdf

This means that using the SoftDevice API permits to put the CPU in sleep and the SoftDevice might wake-up the device from time to time to keep operating Bluetooth. From the point of view of the application, this is "sleep until a Bluetooth event requires the application to react", i.e. an incoming message.

And a nice in-depth review on that 3rd-party blog article:
https://embeddedcentric.com/lesson-14-nrf5x-power-management-tutorial/

[Dennisjoch]

So, theoretically, would this work?

if (enable_imu_wakeup)
{
    // Configure IMU wakeup pin, but do NOT enter System OFF mode
    nrf_gpio_cfg_sense_input(IMU_INTERRUPT_PIN,
                             NRF_GPIO_PIN_NOPULL,
                             NRF_GPIO_PIN_SENSE_LOW);

    // Enter sleep using sd_app_evt_wait() to stay responsive to Bluetooth events
    while (true) {
        sd_app_evt_wait();
    }
}
else
{
    // Enter System OFF mode when IMU wakeup is not enabled
    NRF_POWER->SYSTEMOFF = 1;
    __DSB();
}

I will be able to test this on Friday and will provide an update afterward.

[josuah]

@Dennisjoch
Something like this, although I'd be careful about applying something touching to wake-up to your hardware, as it is easy to brick it.

Good to keep the case detect pin active:
https://github.com/brilliantlabsAR/frame-codebase/blob/main/source/application/main.c#L128-L130

And also, that endless loop never allows you to come back to the application control logic: the lua interpreter would never be run:
https://github.com/brilliantlabsAR/frame-codebase/blob/main/source/application/main.c#L415

The reason why there is this endless loop here is that SYSTEMOFF completely shuts the chip down, and it will next restart at main() when it wakes-up.
https://github.com/brilliantlabsAR/frame-codebase/blob/main/source/application/main.c#L147-L150

You would call that sleep mode from lua eventually, so it would need to return so that you can come back to the lua interpreter after it slept. i.e. so that it can receive the bluetooth data if any.

I would still confirm this with @siliconwitch as it is sensitive bits of the firmware. However, if you work on an nRF52840-DK, there is absolutely no danger! There is a SWD debugger that can almost always get the chip back from the harshest crashes.

https://www.nordicsemi.com/Products/Development-hardware/nRF52840-DK

[Dennisjoch]

@josuah I’ve also been thinking about the loop as a issue, and following your recommendation, I ordered the nRF52840-DK, which should arrive on Friday. I'll take another look and test it when it arrives. Once I know more, I’ll let you know, but your approach already seems like a good one. However, the remaining question will be how this will impact the battery.

[josuah]

I plan to test this when my nRF52840 DK arrives

I am linking the dots now! Thank you I missed it...

The battery usage will certainly be higher, as RAM and radio have to be powered on to keep all the Bluetooth state.

You might have some opportunity to fiddle a bit with the power management API to try to power down more things.

Though, it is also possible that this particular API improves the battery life in some cases: an application that keeps running in a while loop that checks some condition could be greatly power-optimized by instead going to an intermediate sleep state: higher power usage than SYSTEMOFF, lower power usage than a busy loop that constantly wakes-up the CPU for checking the presence of a new Bluetooth packet!