sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE) no effect on power consumption

[Allen]

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.

[Jørgen Holmefjord]

Hi,

• What voltage level is the board powered by? The DCDC regulator will affect the current consumption less if the supply voltage is closer to the minimum supply voltage of 1.7 V.
• What is the measured current consumption? The DCDC regulator will be automatically controlled by the chip, depending on the current draw. It will only be enabled when the current draw is high enough for the DCDC regulator to be more efficient than LDO.
• I assume that the board is populated with the required components for the DCDC regulator?

Best regards,
Jørgen

[Jørgen Holmefjord]

No, only the inductors should be needed to use the DCDC converter. Can you try to enable DCDC at the very beginning of main(), before enabling the softdevice, using the following line?

NRF_POWER->DCDCEN = 1;

Is the current static at 8 mA? If you are entering sleep mode, the current should change depending on the state of the CPU/radio/etc.

Did you use the same method for measuring current on previous board? I would highly recommend the nRF Power Profiler Kit, to measure the current in real-time. This will allow you to see graphs of the current consumption in your firmware at any point of timer.

[hmolesworth]

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

[Jørgen Holmefjord]

hmolesworth, 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.