High Power Consumption - System On

RE: High Power Consumption - System On

Susheel Nuguru — Wed, 28 Jun 2023 14:32:32 GMT

sorry for the late reply, was away for few days.

[quote user="Roiger"]3.8 uA is great for us, but to achieve this we need to add an IDLE state sleep of 600 ms, which is what I was asking if this is standard[/quote]

Ideally in Zephyr RTOS, if you have all threads behaving (yielding) properly, then you should not need to add additional sleep at all. You should make sure that the idle thread in the Zephyr RTOS is able to run most of the time when there is nothing else to do on your application. The only way the idle thread runs is when all the other threads in your application have yielded properly (by k_yield, k_sleep, waiting for semaphore/mutex etc).

The fact that you need to add additional sleep outside the idle thread means that atleast one of your application thread is not yielding. I would try to plug your application to Segger SystemView and see if there are any threads that are running longer than it should without your additional sleep of 600ms.

RE: High Power Consumption - System On

Roiger — Wed, 21 Jun 2023 08:43:42 GMT

We are using k_msleep as you say 🙂

3.8 uA is great for us, but to achieve this we need to add an IDLE state sleep of 600 ms, which is what I was asking if this is standard

RE: High Power Consumption - System On

Susheel Nuguru — Wed, 21 Jun 2023 08:36:54 GMT

In zephyr, the sleep is automatically done in the idle thread. So I am not really sure how you are forcing the sleep?

Making the device go to sleep in main might not be a best way to do it. It is better to use k_mssleep (if you are not using it already).'

Also 3.8uA of current in system on sleep is not bad. How much is your goal to achieve with the RTOS and application running?

RE: High Power Consumption - System On

Roiger — Tue, 20 Jun 2023 15:52:54 GMT

Hi,
We have managed to get down to around 3.8 uA average by changing our sleep logic to:

Sleep X=70 MS every main loop
In addition, if there is no work to do, sleep an additional Y=600 MS every main loop.

This seems like a high amount of sleep to us to acheive this - is this what is to be expected on zephyr?

Thanks!

Roi

RE: High Power Consumption - System On

Roiger — Tue, 20 Jun 2023 08:31:36 GMT

Hi,

As said above, the higher consumption is in system on only.

System off is even slightlu better on our board on zephyr (~0.5 uA ) than on nrf5 sdk (~0.8 uA).

Also as said - the measured 5.8 average is with a peripheral device that uses about 1.5 uA avg, but this overhead exists on our 3.3 uA measurement as well. With the peripheral device off, we acheive 1.8 uA on nrf5 sdk, but 4.3 uA on zephyr.

Thanks!

Roi

RE: High Power Consumption - System On

Susheel Nuguru — Mon, 19 Jun 2023 15:06:44 GMT

I am sorry for late reply, That power consumption does not make sense.Either you have to test this on nRF52833 DK or help me reproduce it at my desk. I do not know any ERRATA that has about 4.5uA of increased current consumption in system off mode on nRF52833.

RE: High Power Consumption - System On

Roiger — Wed, 14 Jun 2023 13:32:18 GMT

Hi,
I thought it best to update that I also tried with a custom_board (as opposed to an overlay on nrf52833dk_nrf52833, and got the same measurements.

RE: High Power Consumption - System On

Roiger — Tue, 13 Jun 2023 14:23:07 GMT

For reference I have tried NCS 2.4.0 and the power consump even goes up a bit (5.9 uA average)

RE: High Power Consumption - System On

Roiger — Tue, 13 Jun 2023 12:40:17 GMT

Hi,
I have attempted to turn off everything in overlay that was not turned off in build/zephyr/zephyr.dts:

&nvic {
    status = "disabled";
};

&i2c0 {
    status = "disabled";
};

&temp {
    status = "disabled";
};

&gpiote {
    status = "disabled";
};

&timer0 {
    status = "disabled";
};

&timer1 {
    status = "disabled";
};

&timer2 {
    status = "disabled";
};

&timer3 {
    status = "disabled";
};

&timer4 {
    status = "disabled";
};

&rtc0 {
    status = "disabled";
};

&rtc1 {
    status = "disabled";
};

&ecb {
    status = "disabled";
};

&ccm {
    status = "disabled";
};

&egu0 {
    status = "disabled";
};

&egu1 {
    status = "disabled";
};

&egu2 {
    status = "disabled";
};

&egu3 {
    status = "disabled";
};

&egu4 {
    status = "disabled";
};

&egu5 {
    status = "disabled";
};

&pwm0 {
    status = "disabled";
};

&acl {
    status = "disabled";
};

&ppi {
    status = "disabled";
};

&mwu {
    status = "disabled";
};

&usbd {
    status = "disabled";
};

&uart1 {
    status = "disabled";
};

&spi3 {
    status = "disabled";
};

&wdt0 {
    status = "disabled";
};

&rng_hci {
    status = "disabled";
};
&ieee802154{
    status = "disabled";
};

The only things not disabled are:

FICR
UICR
Clock
Power
Radio
SPI1 - since we are using this for 2 peripherals
ADC - we use this to measure battery every X hours
RNG
RTC2 - see above
GPIO0
GPIO1
pinctrl

The average power consumption remains 5.8 uA

Thanks!

Roi

RE: High Power Consumption - System On

Roiger — Tue, 13 Jun 2023 11:53:29 GMT

Hi,

As said we have tested this - but I will check again to make sure we have not missed anything 🙂
We were instructed by Nordic personnel to try and stay on the same release we started with for development stage - hence 2.2.0
The level is constant - there are not peaks, it is just that the average is 5.8 instead of 3.3, but the graph seems the same shape in both cases

Thanks!

Roi

RE: High Power Consumption - System On

Susheel Nuguru — Tue, 13 Jun 2023 11:48:24 GMT

The only things I can think about with the info you provided is

Some peripheral might still be enabled. You can check the build\zephyr\zephyr.dts to see if there are any other peripheral that are kept enabled which were not enabled in nRF5SDK.
maybe some errata workaround is missing that you applied in nRF5SDK? We have released NCSv2.4.0 which is more latest. When you are already putting efforts to move from nRF5SDK to NCS, why not move to the latest?
can you connect the power profiler to the app based on nRF5SDK and the app based on NCS and see where the difference in power consumption happens? Do you see any particular spikes or increased current or the increased power is constant over time? It will help us understand the nature of the increase and hence might help us narrow down this to a peripheral that consumes the extra power.

RE: High Power Consumption - System On

Roiger — Tue, 13 Jun 2023 11:36:00 GMT

Hi,

What are you referring to when you mean RTOS timing?
regarding the disable - this is how it was on nrf5SDK - I can try without
I have tried without the RTC(2) instance as well as turning off in prj.conf - the same level (5.8 uA average) occurrs.

Thanks!

Roi

RE: High Power Consumption - System On

Susheel Nuguru — Tue, 13 Jun 2023 11:15:32 GMT

Hmm,

I do not see your flags handling and I assume that you handle them well without introducing any race conditions.

You seems to need dedicated instance of RTC peripheral (RTC2), can't you use the RTOS timing features instead of having a dedicated RTC in this case?

Regarding below

	nrfx_rtc_tick_enable(&rtc, true);
    nrfx_rtc_overflow_enable(&rtc, true);
    nrfx_rtc_tick_disable(&rtc);
    nrfx_rtc_enable(&rtc);

Why do you enable and disable the tick immediately?

What is the current you observe without initializing this addtional RTC(2) instance?

RE: High Power Consumption - System On

Roiger — Tue, 13 Jun 2023 10:58:44 GMT

Hi,
I cannot upload the code itself, but I can outline what is running when I measure these levels:

Within main loop:
- Checking boolean flags - in 99% of the cases the work portion does not happen:
```
			if(flag1 || flag2 || flag3){
				//work
			}
```
- k_msleep(100);

Async during main loop:

Two buttons awaiting interrupts - awaiting on GPIO_INT_LEVEL_ACTIVE

Single shot timer is running, and is restarted every minute:

//definition
K_TIMER_DEFINE(sleep_timer, sleep_timer_elapsed, sleep_timer_stopped);

// start logic
k_timer_start(&sleep_timer, K_MINUTES(1), K_NO_WAIT);

RTC2 is running with 511 prescaler:

const nrfx_rtc_t rtc = NRFX_RTC_INSTANCE(2);

    int ret;
    nrfx_rtc_config_t config = {.prescaler = SYS_TIME_PRESCALER, .reliable = false, .tick_latency = 1,
                                .interrupt_priority = NRFX_RTC_DEFAULT_CONFIG_IRQ_PRIORITY};


    ret = nrfx_rtc_init(&rtc, &config, rtc_handler);
    	if (ret < 0) {
		return;
	}
	nrfx_rtc_tick_enable(&rtc, true);
    nrfx_rtc_overflow_enable(&rtc, true);
    nrfx_rtc_tick_disable(&rtc);
    nrfx_rtc_enable(&rtc);

Thanks!

Roi

RE: High Power Consumption - System On

Susheel Nuguru — Tue, 13 Jun 2023 09:48:55 GMT

What is the main application doing? Since you achieved lower currents in nRF5SDK, it most likely is a configuration issue rather than any hw/sw issue.

But it is hard for me to narrow down the problem with the information given. Can you please provide me the whole application project so that I can try to debug that here?

Also there might be little more overhead in kernel tick handling which might consume little more power than the bate metal examples. I have not benchmarked how much more but should be that big difference like you are observing.