nRF52833 power consumption after upgrade to SDK 1.7.1

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

Simonr — Thu, 17 Feb 2022 08:35:32 GMT

I just confirmed that this setting will disable calibration, and is not recommended for longer use as the RC oscillator will likely drift and go imprecise after some time without calibration. Try adding the dependency described here in your project if it isn't already.

Best regards,

Simon

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

ecsfang — Wed, 16 Feb 2022 07:42:05 GMT

Hi Simon,

Yes, I guessed that was the problem, but I don't really know what to do with the information in the commit.

Again, I use the config (CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION) but I have to disable it (=n) , so I assume that it is not enabled. The other config mentioned in the commit (CLOCK_CONTROL_NRF_FORCE_ALT) is also not user-configurable (get similar compile error should I try to enable it):

error: CLOCK_CONTROL_NRF_FORCE_ALT (defined at drivers/clock_control/Kconfig.nrf:6) is assigned in a configuration file, but is not directly user-configurable (has no prompt). It gets its value indirectly from other symbols.

So, I'm left with the setting CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n and the question if that is correct?

Is it so that the commit fixes problem in the background, i.e. that disabling the RC_CALIBRATION should work ok?

Best regards,
Thomas

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

Simonr — Wed, 16 Feb 2022 07:12:00 GMT

As you can see from the link provided from the Zephyr in the error log, the CONFIG_CLOCK_CONTROL_NRF_DRIVER_CALIBRATION is not user-configurable, but is set from other symbols (that would be the direct dependencies). I assume these (at least CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION) are already enabled in your application. Did you check the details from the commit to this issue?

Best regards,

Simon

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

ecsfang — Tue, 15 Feb 2022 07:43:24 GMT

Hi Simon!

I added the new configuration to my prj.conf file:

CONFIG_CLOCK_CONTROL_NRF_DRIVER_CALIBRATION=y

I then get the following error during compiling:

error: CLOCK_CONTROL_NRF_DRIVER_CALIBRATION (defined at drivers/clock_control/Kconfig.nrf:68) is
assigned in a configuration file, but is not directly user-configurable (has no prompt). It gets its
value indirectly from other symbols. See docs.zephyrproject.org/.../CONF
IG_CLOCK_CONTROL_NRF_DRIVER_CALIBRATION.html and/or look up CLOCK_CONTROL_NRF_DRIVER_CALIBRATION in
the menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration
Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful too.

So, I'm just using "CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n", in which case the new configuration is not used (but maybe I interpret this wrongly?):

if CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION

config CLOCK_CONTROL_NRF_DRIVER_CALIBRATION
bool
depends on !CLOCK_CONTROL_NRF_FORCE_ALT
default y
help
Enabling indicates that calibration is perfomed by the clock control driver.

Again, only with the setting "CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n" (placed in the mcuboot overlay file) will I see an improvement regarding current consumption (dropping ~100uA), removing it will return the consumption to ~145uA from ~50uA.

So, any help in how I should configure correctly would be helpful!

Best regards,
Thomas

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

Simonr — Tue, 15 Feb 2022 07:12:18 GMT

What kind of compile errors are you seeing? I have asked the devs what they recommend for configurations here and will get back to you as soon as I hear from them.

Best regards,

Simon

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

ecsfang — Mon, 14 Feb 2022 06:57:36 GMT

Hi Simon,

Thanks for your reply!

But, I'm not sure how to use this information ...
If I merge the fix you mentioned, I get compile errors if I enable the new configs, and if I leave them default I still get the 100uA extra current consumption.

With the fix merged - what would you say should be the correct way to configure (if the configuration below is not preferred) to get rid of the extra 100uA?

Again, the only configuration I have found so far that removes the extra 100uA (which we only see in SDK 1.7.1 and not in 1.4.1) is the following:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n

Best regards,
Thomas

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

Simonr — Thu, 10 Feb 2022 08:09:01 GMT

Hi Thomas

The picture resolution is fine when I click it, no problem there.

I see. You can check out the "official" fix to this issue here, which I guess would be preferred. Just disabling the RC oscillator calibration will likely cause the crystal to drift, and that will likely affect BLE connections if you're using the radio peripheral at all, and might lead to disconnects and some "off" timers I believe.

Best regards,

Simon

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

ecsfang — Wed, 09 Feb 2022 13:35:37 GMT

Hi again,

Maybe we found the problem - at least a way around it.

Found another issue related to 1.7.1 (https://devzone.nordicsemi.com/f/nordic-q-a/81418/bug-in-ncs-v1-7-1-with-32khz-rc-oscillator-and-mcuboot-enabled), and if I apply the solution given there to our build, the 100uA is lost.

So, in my local mcuboot.conf I added (since CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y is in my config):

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=n

and with that I'm back to my ~60uA current consumption.

Is there any other better or preferred solution to this?

Best regards,
Thomas

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

ecsfang — Wed, 09 Feb 2022 08:04:19 GMT

Hi Simon,

Thanks for your reply, yes I could share the configuration file, but first I like to tell what I found last evening.

As mentioned, when we compile and run using SDK 1.4.1 we end up at about 60uA in idle, but building same app for SDK 1.7.1 results in ~140uA.

So, I went through all pins and peripherals to see if I could find what caused this, and I ended up in the configuration

CONFIG_BOOTLOADER_MCUBOOT=y

If I compile and run with this setting (also included in the 1.4.1 build) I get ~140uA (shown in yellow in the picture), but if I remove this setting I end up with the original ~60uA (shown in red).

So, with this finding I have the following result:

CONFIG_BOOTLOADER_MCUBOOT=y in SDK 1.4.1 results in ~60uA

CONFIG_BOOTLOADER_MCUBOOT=y in SDK 1.7.1 results in ~140uA

CONFIG_BOOTLOADER_MCUBOOT=n in SDK 1.7.1 results in ~60uA

I found a similar issue (https://devzone.nordicsemi.com/f/nordic-q-a/59709/config_bootloader_mcuboot-costing-hundreds-of-ua), but if I try the solution given there I see no difference, I only see the difference if I turn the configuration off (CONFIG_BOOTLOADER_MCUBOOT=n).

Any ideas about this?

Best regards,

Thomas

(Sorry about the picture - I don't know how to include with higher resolution - it worked in the original post ... :( )

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

Simonr — Tue, 08 Feb 2022 13:50:34 GMT

Hi Thomas

Would it be able to get the project configuration or a small sample project so we can reproduce this on our end, no luck in finding someone seeing the same behavior thus far I'm afraid.

Best regards,

Simon

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

ecsfang — Tue, 08 Feb 2022 07:28:48 GMT

Hi Simon,

The main application handles a modem and some I2C devices. When sleeping, the power to both the modem and the I2C devices are off and should not interfere.

In my test-application, I do the same, I just turn off the voltage regulators and make sure all pins are in a defined state.
If I compile and link with SDK 1.4.1 I end up with ~60uA, but if I take the same code and compile and link with 1.7.1 then I see the peaks shown above and I end up with ~140uA instead.

It is a custom build board, and I use the same hardware etc, it is just SDK 1.4.1 that is replaced with SDK 1.7.1, so my guess is that either I have missed something (and SDK 1.4.1 is more "forgiving") or SDK 1.7.1 needs some other configuration. If I would have missed some peripheral, then I would presume that 1.4.1 would behave the same as 1.7.1?

When the application is sleeping, I see exactly the same current consumption as in my test-program.
The (very) simple test-application basically looks like this (I did this just to measure the current consumption while sleeping so it is not doing anything apart from "sleeping" - not timers or interrupts are initialized from my code):

void main(void)
{

... init all pins, turn off voltage regulators, SPI, UART and I2C etc ...

while (1) {
k_sleep(K_FOREVER);
}

}

Best regards,
Thomas

RE: nRF52833 power consumption after upgrade to SDK 1.7.1

Simonr — Tue, 08 Feb 2022 06:49:00 GMT

Hi Thomas

What peripherals are your application using here, and what exactly does your application do? Seems like one or more of the peripherals haven't been disabled/turned off properly. What function is your application in when running in this mode. Can you also share some details on the board you're measuring this current from. Is it a custom board or an nRF52833 DK?

Best regards,

Simon