nRF52833 power consumption after upgrade to SDK 1.7.1

[ecsfang]

Hi,

After upgrade from nRF Connect SDK 1.4.1 to SDK 1.7.1 we have seen an increase of the current consumption with about 100uA.

Before with SDK 1.4.1 the idle current was about ~60uA, but now we see peaks with about 300uA at about 300Hz (see included picture).

I have tested both with our main application as well with a simple test application (that just initialize all pins then goes into idle).

I have also tested on two different product samples, and the scenario is the same, but the frequency differs from 2.7ms to 3.4ms (290-370Hz).

At this stage we are not using BLE, and the test application just initialize all pins, powers off all external sensors etc and just goes into idle. We just rebuild our applications with the API changes that was needed between 1.4.1 and 1.7.1 so our code is the "same" in both scenarios.

Any ideas why this differs between the two SDK's? Could it be something that we have missed to configure when upgrading from 1.4.1 to 1.7.1 that causes these 300Hz power peaks?

Best regards,
Thomas

[Simonr]

Hi

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

[ecsfang]

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