nrf_pwr_mgmt_run impact of SCB_SCR_SLEEPDEEP_Msk

[M. David.]

Hi

I could not really find a satisfactory answer to my question, what (if any) impact has the setting of the SLEEPDEEEP bit before calling nrf_pwr_mgmt_run? I'm wondering if the SD in  sd_app_evt_wait() overwrites those registers anyway or what it is doing, from what I read is, that it internally also calls the _WFE instruction.

// Set SLEEPDEEP bit of Cortex System Control Register
SCB->SCR |= (uint32_t)SCB_SCR_SLEEPDEEP_Msk;
nrf_pwr_mgmt_run();

Setup:

• nrf52840
• SDK 17.x
• Using the SD 140 (enabled)

Further questions:

1. Are HFCLK and LFCLK runing in SYSTEM_ON mode? Does SLEEPDEEP have any impact on this?
2. Does the system wakeup from a timer peripheral interrupt/expiry? TIMER4 in this case system.
3. Does the system wakeup from the RTC interrupt/expiry.

How I would approach low power consumption with my current knowledge:

• disable unused peripherals
• configure perhipherals from which the system shall wakeup from sleep
• call nrf_pwr_mgmt_run() within the main loop.

Is this approach reasonable?

Thanks in advance for any help.

Cheers David

[Albrecht Markus Schellenberger]

Hello David, 

Our nRF5 SDK / SoftDevice experts are out of office today. We will come back to you in the beginning of next week. 

Cheers, 

Markus 

[Vidar Berg]

Hello,

The SLEEPDEEP bit is not relevant on the nRF52 series as we incorporate our own Power management unit (PMU) in the  design.

1. The LFCLK will keep running in system ON if it has been requested by the application. But it should not have too much impact on the sleep current (< 1uA with LFXO, see sleep currents). This clock source is often used as wakeup source and for timekeeping through the app_timer_* APIs.

HFCLK, on the other hand, will automatically be released in sleep as long as it is not being requested by any of the peripherals in system ON.

2. Yes, any interrupt source will cause the chip to wake up from system ON. The problem with the TIMER though is that it requires the HFCLK to be kept active in sleep (System ON idle current with TIMER running). So if the goal is to reduce the idle current, you should consider using the RTC instead.

3. Yes.

Best regards,

Vidar

[M. David.]

Hi Vidar

If  the LFCLK is sourced from the internal RC oszillator and the calibration mechanism is enabled to have a greater accuracy. Does this mean the HFCLK is also kept running in system ON mode (for the calibration)?

We only have an external crystal oscillator HFXO but no LFXO, if the above is true, is there a way to go to system ON, while the SD is enabled, but not have the HFCLK running?

Maybe this is managed by the SD and it disables the calibration for the system ON?

Cheers

David

[Vidar Berg]

Hi David,

The HFXO will only be kept active for the duration of the calibration events, so the impact on your total average current consumption should be quite limited. You may use our online power profiler to estimate what the difference between using the internal RC oscillator and a crystal would have been for your application.

When using the Softdevice, the calibration will run in the background without any involvement from the application. All the application has to do is to specify the clock source and calibration interval when enabling the stack with sd_softdevice_enable().

Cheers,

Vidar