This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Optimize power for nRF52

I am still noticing a higher than expected power draw on my nRF52 and I want to make sure I have adopted best practice in turning things off/optimising things before entering sd_app_evt_wait(); It appears to be in the vicinity of 700 uAmps currently.

For this particular device I have a button which I am using with the app_button library in the v11 SDK. As far as I can see this is using GPIOTE port to sense the button which is best practice as I understand it.

I also have a TWI sensor which I power down after each reading by

uint32_t *twim0_power = (uint32_t *)(NRF_TWIM0_BASE+0xFFC);
*twim0_power = 0;   //turn off TWIM0
*(volatile uint32_t *)twim0_power;    //wait for register to be written (CPU runs faster than the peripherals)
*twim0_power = 1;   //turn on TWIM0
nrf_drv_twi_disable(&m_twi_instance);
nrf_drv_twi_uninit(&m_twi_instance);

I have plenty of app_timers that I stop and start but these use the RTC and in any respect I have #define TIMER1_ENABLED 0 in my configurations so I don't think the nRF52 errata regarding the TIMER module should be a problem.

I don't use the UART (I used BLE NUS extensively) so I don't even init it in Main. However I still have #define UART0_ENABLED 1 in configurations.

I use SAADC to take a battery reading but I enable/disable this after each reading.

I do a floating point calculation so my power_manage() function looks like this

static void power_manage(void)
{

    uint32_t err_code;
    __set_FPSCR(__get_FPSCR()  & ~(FPU_EXCEPTION_MASK));      
    (void) __get_FPSCR();
    NVIC_ClearPendingIRQ(FPU_IRQn);
    err_code = sd_app_evt_wait();
    APP_ERROR_CHECK(err_code);
}

Is there anything else I ought to be doing before entering sd_app_evt_wait()?

Parents
  • Hi

    This is usually trial and error process. Comment out any custom code that enables different peripherals until you get the expected low current consumption. Then hopefully you will see what causes the current consumption. 700uA hints that some peripheral is enabled that requires a high frequency clock source. You could start with trying not to initialize the TWI.

    It should be ok to leave #define UART0_ENABLED 1. It should not consume any current as long as you do not initialize the UART.

Reply
  • Hi

    This is usually trial and error process. Comment out any custom code that enables different peripherals until you get the expected low current consumption. Then hopefully you will see what causes the current consumption. 700uA hints that some peripheral is enabled that requires a high frequency clock source. You could start with trying not to initialize the TWI.

    It should be ok to leave #define UART0_ENABLED 1. It should not consume any current as long as you do not initialize the UART.

Children
Related