nRF52833 power consumption after upgrade to SDK 1.7.1

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

  • 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

  • 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

  • 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

  • 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 ... :( )
  • 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

Related