Reducing current consumption on an RTC based application

RE: Reducing current consumption on an RTC based application

user2111 — Mon, 30 May 2022 07:52:59 GMT

Hello again, good to hear that you have found the issue! I can confirm that the 400uA is an approx value, and it will vary around ~400uA (even down to ~340uA). It can happen for both TWIM and TWI. I guess the reason for not mentioning TWI in specific for the errata is that TWI is deprecated, since TWIM is preferred:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/memory.html#topic

Best regards,
Kenneth

RE: Reducing current consumption on an RTC based application

user74012 — Wed, 25 May 2022 20:32:40 GMT

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.

RE: Reducing current consumption on an RTC based application

user74012 — Wed, 25 May 2022 20:25:58 GMT

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?

RE: Reducing current consumption on an RTC based application

user74012 — Tue, 24 May 2022 21:34:37 GMT

Hi, this was not about addressing hard faults, it was more to point out that GPIOTE Errata that I followed didn't help reducing the consumption, and only made my TWI peripheral misbehave.

RE: Reducing current consumption on an RTC based application

user2111 — Tue, 24 May 2022 15:21:15 GMT

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

RE: Reducing current consumption on an RTC based application

user74012 — Tue, 24 May 2022 15:02:14 GMT

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.

RE: Reducing current consumption on an RTC based application

user2111 — Tue, 24 May 2022 14:57:14 GMT

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

RE: Reducing current consumption on an RTC based application

user74012 — Tue, 24 May 2022 14:31:21 GMT

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.

RE: Reducing current consumption on an RTC based application

user74012 — Tue, 24 May 2022 14:27:02 GMT

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

[quote userid="2111" url="~/f/nordic-q-a/88151/reducing-current-consumption-on-an-rtc-based-application/369186#369186"]What do you get?[/quote]

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.

RE: Reducing current consumption on an RTC based application

user2111 — Tue, 24 May 2022 07:37:15 GMT

[quote user="Wesperos"]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?[/quote]

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.

[quote user="Wesperos"]When I disable my peripherals, SPI and TWI, consumption doesn't get much lower than my initial one[/quote]

What do you get?

Kenneth

RE: Reducing current consumption on an RTC based application

user74012 — Mon, 23 May 2022 22:16:46 GMT

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?

RE: Reducing current consumption on an RTC based application

user2111 — Mon, 23 May 2022 19:18:45 GMT

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

RE: Reducing current consumption on an RTC based application

user74012 — Mon, 23 May 2022 18:01:47 GMT

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

[quote userid="65515" url="~/f/nordic-q-a/88151/reducing-current-consumption-on-an-rtc-based-application/369092#369092"]Related to this is the floating point hardware ever used (intentionally or not)?[/quote]

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

RE: Reducing current consumption on an RTC based application

user74012 — Mon, 23 May 2022 17:52:52 GMT

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?

RE: Reducing current consumption on an RTC based application

user65515 — Mon, 23 May 2022 15:13:30 GMT

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)?

RE: Reducing current consumption on an RTC based application

user2111 — Mon, 23 May 2022 12:45:08 GMT

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

Kenneth

RE: Reducing current consumption on an RTC based application

user74012 — Mon, 23 May 2022 10:10:17 GMT

Unfortunately, I am not allowed to share it. What I can say is that the board is free from shorts and damages, and when I run basic program without any peripherals, the consumption is low as it should be. And when I do run peripherals, they work just fine. So I assume that configuration of my libraries and peripherals is the issue hiere. Maybe I'm wrong?

RE: Reducing current consumption on an RTC based application

user103465 — Mon, 23 May 2022 10:04:26 GMT

Could you share chematic of your custom board with nRF52832. Maybe there are some issues inside? What is LDO do you use?

RE: Reducing current consumption on an RTC based application

user74012 — Mon, 23 May 2022 09:35:36 GMT

ok thanks. I'll wait and see if some of Nordic app engineers will have some ideas on reducing power SDK framework.

RE: Reducing current consumption on an RTC based application

user103465 — Mon, 23 May 2022 09:33:04 GMT

Zephyr is RTOS. RTOS is when all function are in your hands. Install NRFConnect ide 1.9.1

RE: Reducing current consumption on an RTC based application

user74012 — Mon, 23 May 2022 09:18:21 GMT

ok, thanks. How would Zephyr make it consume less power?

RE: Reducing current consumption on an RTC based application

user103465 — Mon, 23 May 2022 09:14:03 GMT

I would recomend to use nrfConnect IDE based on Zephyr.

RE: Reducing current consumption on an RTC based application

user74012 — Mon, 23 May 2022 07:42:34 GMT

Hi, no, I dont use SAADC. Here is the screen shot of every driver and SDK library used in my application:

so as you can see, it's the basics. I want to add that I have commented out all of uart -related functions, and thus saved myself decent 2 mA.

RE: Reducing current consumption on an RTC based application

user103465 — Sat, 21 May 2022 07:48:45 GMT

Hi do you use SAADC in your application? Write list of working peripheral