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 Reply Children
  • There are occasions when sd_app_evt_wait() doesn't; test this by toggling a spare io pin high before and after this call and check on the 'scope that the intended sleep period isn't exited prematurely. Ignore this comment if you have already tried that. Also ensure SD is actually 7.2.0, which hopefully it is, as changes were made to this function.

    Related to this is the floating point hardware ever used (intentionally or not)?

  • Hi Kenneth, thanks for the useful link. Love the tips I found in there. I found a similar blog post before, but it seems to be a for a different chip, ages old, and not very applicable for my problem. That is, I have checked most of points, and they are fine. However in the post you've linked, I find some interesting parts:

    You think you’re in SYSTEM_ON mode with the CPU off but you measure 100’s of uA. You’ve left a peripheral on, maybe intentionally. If you left logging enabled through the UART, this will also use this amount of current. Turn off UART logging in the sdk_config.h file in favor of RTT. RTT will not use current unless the debugger is connected.

    Can you explain me the reasoning behind this? Should I turn off the peripherals everytime before going to sleep? For example, I'm using a TWI based sensor, that gets readout every 5min or so. Should I turn off the TWI peripheral and re-initialize sensor on every wakeup, that is, every 5min? Is that really so?

    Another point that made me curious:

    Be aware that single-pin GPIOTE interrupts may use more power than Port GPIOTE interrupts depending on the scenario.

    What does this mean? I have an interrupt at GPIO pin, but Im not sure if it port or a single pin? How to check and set it up? And how much consumption difference are we talking about here?

  • I'm using s132_nrf52_7.2.0_softdevice.hex, so I guess this is fine?

    Related to this is the floating point hardware ever used (intentionally or not)?

    Glad you asked, I am, indeed. using some floating point operations. How much current consumption should I count on there?

  • You need to try and fail a bit to find what is likely causing the current consumption in your application, this is typically done by not using a specific peripheral and/or disable when not used. In most part there should be a low power section for a peripheral that describe how to achieve low power usage, e.g.:
    https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/twim.html#concept_twi_low_power 

    You can read about the difference about IN(INPUT) and PORT event here:
    https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/gpiote.html#concept_knz_kww_lr 

    You may need to look at the actual register configuration to find which type of event is used for wakeup, if you are using the gpiote driver then typically configuration/enabling of "high accuracy" translate to IN event.

    For GPIOTE in specific also check out these two errata's:
    https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev3/ERR/nRF52832/Rev3/latest/anomaly_832_89.html 
    https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev3/ERR/nRF52832/Rev3/latest/anomaly_832_97.html 

    Best regards,
    Kenneth

  • Hello, I tried and failed a bit as you said, but wasn't really able to get very far. When I disable my peripherals, SPI and TWI, consumption doesn't get much lower than my initial one. Only if I totally turn off all peripherals and my main loop is left only with sd_app_evt_wait(), do I get the really low consumption.

    Is there something else to check, like the clock or various nrF libraries like ringbuffer, scheduler etc that are taken over by default from the ble_app_uart example?

Related