• State Verified Answer
  • Locked Locked
  • Replies 24 replies
  • Subscribers 76 subscribers
  • Views 3709 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289396
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Reducing current consumption on an RTC based application

Pero Krivic

Hello nRF people!

I am developing an application on a custom board with nRF52832, that consumes way too much current, more than intended, and I'm looking for the ways to reduce the consumption. 

The application is heavily based on nRF-SDK v17.1.0 pre-given examples and libraries, and it goes like this:

The application builds on top of the ble_app_uart example, where advertiser runs for cca 30s and is turned off. No BLE radio is used ever again, but S132 remains in control of the program (like for example sd_app_evt_wait function used to put it to sleep). The application keeps libraries like app_timer, app_uart, and power_management. Now comes the second part - after the BLE is turned off, a couple of chips (sensors) that are accessed via TWI and SPI are initialized. The sensors are readout and the application goes to the SysrtemON sleep mode. The application uses couple of timers based off app_timer library (that utilizes RTC1) as well as direct RTC2 to wake up every couple of minutes and handle the sensors. All of this uses 2 - 4 mA, even tough the device spends most of the time in the systemON mode. 

I have double checked my board to ensure there are no current leaks anywhere, and I have run a simple blinky app to make sure that device goes to sleep and when it does, the total consumption falls to less than 10uA. The sensors are rated to less than 10uA each.

This made me believe it is my application software that drains all that current, so I looked around to see what can I turn off. I turned off app_uart and everything related to UART or UARTE, including my retartgeted printf. This cost me my beloved debug printout, but it did reduce current consumption to cca 0.5mA. So it's good. Now my application handles a couple of timers from app_timers2.c and one RTC2 timer, but the consumption is still high. What do you think, what makes this leak and what do you suggest to try out to reduce the consumption?

Parents
  • +1

    Hello, I am coming back with some good news - I managed to reduce the current consumption from 340uA to 50uA. How cool is that?! How did it happen - well it was the Errata thing after all ([89] GPIOTE: Static 400 µA current while using GPIOTE) What I failed to do the first time was to  disable and de-initialize the TWI completely, and then add that errata code. When the sensor readout is needed again, both TWI and the sensor ought to be re-initialized. 

    So to wrap it up, my current saving code looks like this:

    void sensor_readout(){
    lis3dh_init();      // This is where TWI0 is initialized and enabled
    lis3dh_setup();     // This is where the sensor is configured
    
    inclination = lis3dh_inclination();
    printf("\n\rInclination: %.3f", inclination);
    
    lis3dh_disable();   // This is where the nrf_drv_twi_disable() is called
    rak_i2c_deinit();   // This is where nrf_drv_twi_uninit() is called
    
    // Errata [89] Fix: Static 400 µA current while using GPIOTE
    *(volatile uint32_t *)0x40003FFC = 0;
    *(volatile uint32_t *)0x40003FFC;
    *(volatile uint32_t *)0x40003FFC = 1;
}

    What still bothers me with this fix is that the Errata code was crucial to make this happen, but my conditions are different than what Errata presumes:

    • My initial consumption was less than 400uA (it was 340uA). Is this just the approximate value or is it really so?
    • I am not using TWIM at all. I am using legacy TWI drivers.

    Any thoughts on this?

Reply
  • +1

    Hello, I am coming back with some good news - I managed to reduce the current consumption from 340uA to 50uA. How cool is that?! How did it happen - well it was the Errata thing after all ([89] GPIOTE: Static 400 µA current while using GPIOTE) What I failed to do the first time was to  disable and de-initialize the TWI completely, and then add that errata code. When the sensor readout is needed again, both TWI and the sensor ought to be re-initialized. 

    So to wrap it up, my current saving code looks like this:

    void sensor_readout(){
    lis3dh_init();      // This is where TWI0 is initialized and enabled
    lis3dh_setup();     // This is where the sensor is configured
    
    inclination = lis3dh_inclination();
    printf("\n\rInclination: %.3f", inclination);
    
    lis3dh_disable();   // This is where the nrf_drv_twi_disable() is called
    rak_i2c_deinit();   // This is where nrf_drv_twi_uninit() is called
    
    // Errata [89] Fix: Static 400 µA current while using GPIOTE
    *(volatile uint32_t *)0x40003FFC = 0;
    *(volatile uint32_t *)0x40003FFC;
    *(volatile uint32_t *)0x40003FFC = 1;
}

    What still bothers me with this fix is that the Errata code was crucial to make this happen, but my conditions are different than what Errata presumes:

    • My initial consumption was less than 400uA (it was 340uA). Is this just the approximate value or is it really so?
    • I am not using TWIM at all. I am using legacy TWI drivers.

    Any thoughts on this?

Children
Related
Terms of service