Minimizing power consumption

[Tim Adu]

Here's is my device profile:

• Running on SDK 15.2.0
• FreeRTOS
• Custom board, based on NRF52840
• Powered by a 3.5Ah battery
• Using CLI utility
• Using the following peripherals
  
  • I2C
  • ADC
  • NRF CRYPTO
  • UART (app_uart with fifo)
  • NFC
• Softdevice is integrated, but no BLE features have been implemented yet. Softdevice is therefore not enabled yet
• A couple of sensors and a modem

The goal is to put the device in the lowest possible power savings mode (SYSTEM OFF). Here's what I've done/tried so far:

• Stopped/disabled all peripherals (except CRYPTO and NFC; the device needs to be woken up from SYSTEM OFF via NFC). Disabling CRYPTO does not seem to have any effect.
• Disabled power to the sensors and modem via GPIO pins
• Tried NRF_CLOCK->TASKS_HFCLKSTOP = 0; and SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk,
• Disabled NRF_LOGGER
• Optimized code for size
• FreeRTOS Tickless Idle
• Reset GPIOS to default states
• Stopped all timers

After implementing all these measures, the device runs at 4.5mA in SYSTEM OFF mode, using the power profiler kit. This is not optimal, as I'd like to see the current consumption in the  micro amps range.

Any insights? Any and all ideas are appreciated. Thanks

Tim

[Håkon Alseth]

Hi,

 

Static 4.5 mA current consumption?

Are you by any chance in debug mode while checking this? Emulated system off, which will run in debug mode, will not give the expected result in terms of power consumption, and it is recommended that you add a while(1) loop after the call to system off in your firmware, for debugging purposes.

If you power cycle your device, it should go out of debug mode.

 

Kind regards,

Håkon

[Tim Adu]

Yes, it's static 4.5 mA.

I use Segger Embedded Studio to develop the application.

I have test setup that generates a production image, which contains the application (built using the Release config, not Debug), SoftDevice and Bootloader. After loading the image, then I start the PPK to do power consumption readings.

Tim

[Håkon Alseth]

Try power cycling the board, then measure with the PPK.

 

Cheers,

Håkon

[Tim Adu]

I've tried that; the board is power cycled always before starting measurements.

Tim

[Håkon Alseth]

Good, then its not the nRF itself that is causing this, unless you are getting an assertion or similar.

When you enter SYSTEMOFF, all clocks are stopped, GPIOs are latched in their current configuration, and the nRF itself should not draw much power. Only way to wake up is on pin or reset.

 

However; if the GPIOs are latched as output, with either '1' or '0' towards an external device (LED, IC, or anything else), then that might draw current.

Could you check your GPIO configuration to ensure that there is nothing external that is misbehaving due to the latched GPIO settings? 

 

Kind regards,

Håkon

[Tim Adu]

As the very last step before calling the SHUTDOWN function

nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF);

I reset all GPIO pins that are used by the application to their default states using nrf_gpio_cfg_default

Does it make sense to do this?

[Håkon Alseth]

nrf_pwr_mgmt will execute a number of handlers before entering sleep, where that is defined on how many you have registered in your application via NRF_PWR_MGMT_HANDLER_REGISTER(my_pwr_mgmt_handler, PRIO), and if any of these returns false, it will not go to sleep.

If you do not have any handlers registered, then it'll go to systemoff directly.

 

Don't you have any pins to wake up on? Are you relying on NFC to wakeup?

Have you entered debug mode to see if the call to sd_power_system_off() in nrf_pwr_mgmt.c is called ?

[Tim Adu]

Thanks! It definitely helped. Managed to bring it down to 65uA in SYSTEM OFF. I had defined a dummy handler which was not returning true. I defined the shutdown sequence in my application but did not set the dummy handler to return true.