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?

[Kenneth]

Check out:
https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/optimizing-power-on-nrf52-designs

Kenneth

[Pero Krivic]

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?

[Kenneth]

Pero Krivic said:

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?

I can't imagine so. When doing these measurements also make sure are measuring the nRF alone to ensure that it's not current by the sensors that are the ones that are drawing the current you experience here.

Pero Krivic said:

When I disable my peripherals, SPI and TWI, consumption doesn't get much lower than my initial one

What do you get?

Kenneth

[Pero Krivic]

I am pretty positive that nRF is measured alone. When I run an empty example, the current consumption is negligible. 

Kenneth said:

What do you get?

In normal state, when both SPI and TWI are both active, program does its thing and consumes cca 340uA. When I decide to comment out everything related with TWI, but leave the SPI, the consumption falls to cca 312 uA. If I do the oppostite, leave TWI and comment out SPI, the value is exactly the same. 

Oh and by the way,  later on I have tried disabling the peripherals with NRF_TWI0->ENABLE = 0 just before invoking sd_app_evt_wait() and then adding NRF_TWI0->ENABLE = 1 just after it, and didn't achieve much. There was no difference in the current consumption, but my TWI sensor got all messed up and wouldn't give out any data anymore.

[Kenneth]

Remember that when you are disabling the peripherals, then the pins will fall back to the GPIO configuration, so you should ensure that you configure the GPIO to a reasonable logic level while the peripheral is disabled, this should ensure for instance that not any connected sensor enter an invalid state due to unintentional configuration due to pin level. You may need a logic analyzer to check this works as expected. Please have in mind that any configured sensor may draw current while configured, so based on your description I am not fully convinced that your sensors are not part of the problem here, if you are able to cut power to them (at least for test) that may still be a good test when you experience elevated current.

Kenneth

[Pero Krivic]

Makes perfect sense, thanks for your prompt response!

May I ask to point me to an example where peripherals are properly disabled and enabled again after the wakeup call, and GPIOs properly configured. I'm struggling to get out of the enable/disable mess and I see no improvement in current consumption.

Oh and btw, I made another post about your errata tip, but I couldnt tag you, so hopefully you've seen it by  now.

[Pero Krivic]

Hello I tried various combinations with GPIOTE initializations, mostly to initialize my TWI pins into outputs with either high or low state, or into inputs, and I did this all in the main like this:

ret_code_t err_code;

err_code = nrf_drv_gpiote_init();
APP_ERROR_CHECK(err_code);

// Config TWI pins as for a default state 
nrf_drv_gpiote_out_config_t out_config = GPIOTE_CONFIG_OUT_SIMPLE(true);  // configure to be output high

err_code = nrf_drv_gpiote_out_init(I2C_SCL_PIN, &out_config);
APP_ERROR_CHECK(err_code);

err_code = nrf_drv_gpiote_out_init(I2C_SDA_PIN, &out_config);
APP_ERROR_CHECK(err_code);

Unfortunately, this turned out to have no influence on the current consumption. What did help with the current consumption was the proper implementation of the Errata code, that I just posted in another comment in this thread, but it left me with some peculiarities. Feel free to check it out and see what was going on.