This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE) no effect on power consumption

Hello,

I am working on a wearable device and need the lowest power consumption possible. The project configuration is:

  • S132 7.2.0
  • SDK 17.0.2

The board is powered with a bench power supply which displayed current to mA resolution. I am not seeing any difference in power consumption when the DC/DC regulator is enabled. In previous projects there was a significant difference when this feature was enabled. It does not matter if it is before or after enabling the soft device/BLE.

  • Yes, the soft device is initialized before enabling the DC-DC mode. This is done with the BLE stack is initialized.

    Verified with a debugger that NRF_POWER->DCDCEN is 0 before the call and 1 after the call.

    Should the power consumption drop immediately after the DC-DC is enabled? Where can I find a description of the operation?

    I have a Power Profiler Kit on order. It is currently back ordered. Will try when that arrives.

  • Yes, the current should drop immediately. I created a test-project to show this, which has a 3s delay at the start of main, then enable DCDC, then just busy-loops:

    int main(void)
    {
        nrf_delay_ms(3000);
        NRF_POWER->DCDCEN = 1;
    
        while (true);
    }

    The result can be seen in below capture from the PPK:

    As you can see, I marked the area where the current consumption is high is 2.962s (if I had marked the area more precise, I'm sure it would have been very close to exactly 3s).

  • I can confirm the Rigado BMD-350 works as expected on our boards, although we use "true" as a parameter to the function and not the definition in nrf_soc.h. This is not your problem, but I would prefer Nordic to not mix types like this. An enum generating a value of 1 by assuming the compiler does not use other than assignment from 0, 1, .. in the definition in order to represent a boolean value is dodgy

    /**@brief DC/DC converter modes. */
    enum NRF_POWER_DCDC_MODES
    {
      NRF_POWER_DCDC_DISABLE,          /**< The DCDC is disabled. */
      NRF_POWER_DCDC_ENABLE            /**< The DCDC is enabled.  */
    };

    If this must be kept, at least force the initial value:

    /**@brief DC/DC converter modes. */
    enum NRF_POWER_DCDC_MODES
    {
      NRF_POWER_DCDC_DISABLE = 0,      /**< The DCDC is disabled. */
      NRF_POWER_DCDC_ENABLE            /**< The DCDC is enabled.  */
    };

    Better still, maybe show how these values are expected to be used:

    /**@brief DC/DC converter modes. */
    enum NRF_POWER_DCDC_MODES
    {
      NRF_POWER_DCDC_DISABLE = false,  /**< The DCDC is disabled. */
      NRF_POWER_DCDC_ENABLE  = true    /**< The DCDC is enabled.  */
    };

    Is it a problem in this case? Not with this SES compiler:

    STATIC_ASSERT( (NRF_POWER_DCDC_ENABLE) == true, "((NRF_POWER_DCDC_ENABLE) == true fails"); // Check

  • , not sure what you mean by mixing of types. The API documentation say that the input to sd_power_dcdc_mode_set() should be of type NRF_POWER_DCDC_MODES, not a boolean value. 

    The C99 standard specification draft specify the default first enumerator constant and increment if no constant is defined:

    "An enumerator with = defines its enumeration constant as the value of the constant expression. If the first enumerator has no =, the value of its enumeration constant is 0. Each subsequent enumerator with no = defines its enumeration constant as the value of the constant expression obtained by adding 1 to the value of the previous enumeration constant."

    Similar statements can be found in C11 and C++1y drafts. Unless you are using a compiler that does not follow the specifications, the enum should have the correct values. NRF_POWER_DCDC_MODES is declared in the softdevice header file, so it will be used inside the softdevice as well. The softdevice will not use boolean values, unless you falsely pass boolean values to the function-call.

  • Hello Jorgen,

    Either I don't have the PPK setup properly or there may be a hardware issue? Below is a screen capture at startup. It appears that the baseline power consumption is [email protected] with only the BLE initialized. When the DCDC regulator is enabled the consumption actually went up! The capture you provided suggests that the baseline power should be around 5mA and with DCDC enabled it goes lower. I captured this several times to make sure my eyes were not deceiving me.

    Thoughts?

Related