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

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
  • Hello @Kenneth in response to your comment on GPIOTE Errata, I found it really interesting that GPIOTE is able to leak extra 400uA: That's not exactly the order of magnitude I'm dealing with, but I gave it a try. I copypasted the code from the Errata:

    *(volatile uint32_t *)0x40004FFC = 0;
    *(volatile uint32_t *)0x40004FFC;
    *(volatile uint32_t *)0x40004FFC = 1;
    

    and again, didnt achieve much. Just messed up my sensor which made my app end up in the hard fault section.

  • I don't think you should worry too much about your sensor go to hard fault etc at the moment after for instance wakeup/resuming operation, the main focus should be what is causing the current consumption, and to locate the cause you need for testing try to disable "things", once we locate what is causing the excessive current you can start thinking of handling/workaround possible asserts or errors.

    Kenneth

Reply
  • I don't think you should worry too much about your sensor go to hard fault etc at the moment after for instance wakeup/resuming operation, the main focus should be what is causing the current consumption, and to locate the cause you need for testing try to disable "things", once we locate what is causing the excessive current you can start thinking of handling/workaround possible asserts or errors.

    Kenneth

Children
Related