BL652 vs nRF52832 DK - Current Draw Configuration Differences

[smartventSystems]

Hello,

I have been developing on a nRF52832 DK using nRF5 SDK v17.1.0, and am very close to a production ready state. The final program will use soft devices, app_timers, and multiple uart connections across peripherals and central connections. Because the final version of the hardware was supposed to run on a battery powered BL652 Laird module, I decided to try flashing it over to run tests. After I changed the sdk_config file to run the Softdevice clock on the internal RC instead of the crystal oscillator, it runs fine.

However, the current draw of the module is far more than on the development kit. On the development kit, my project runs around 0.06mA (in between radio transmissions), but on the BL652 module using a voltage regulated 1.8V, it draws closer to a steady 4 - 5mA instead! I can decrease this by using a voltage regulated 3.3V, but that still pulls around 1 - 2 mA. This is obviously still drastically more than what I was expecting, since I was using basically the same code for the development kit as the Laird module except for the clock configuration. I also don't really know why the module's current consumption would change since both voltages are within the allowed range for the module and the nRF52832 chip.

I tried running the basic ble_app_uart project example on it, and I was still getting around 4-5 mA. 

I tried running the basic blinky project example on it, and I was still getting around 2-3 mA.

So clearly, I'm doing something wrong here.

Are there any other changes that I should make in the configuration on top of the NRF_SDH_CLOCK_LF_(SRC / RC_CTIV / RC_TEMP_CTIV / ACCURACY) to use the RC clock instead to maintain proper usage on the BL652 module while keeping current draw similar to the development kit?

Does the lengthening of the radio transmission openings due to NRF_SDH_CLOCK_LF_ACCURACY really increase the power consumption that drastically?

Would switching to an external crystal oscillator really fix everything?

I copied this code over 'sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);' without really understanding how it would impact my power consumption because I heard somewhere that it decreases current consumption on the development kit. Does this have an opposite effect on the BL652 modules?

I've attached the sdk_config that I have been using for the project development. I have been using Segger to build and run the projects. 

Any insights or help would be greatly appreciated.3223.sdk_config.h

[Simonr]

Hi

First off, how are you measuring the current consumption on your DK and module exactly? What is the average current consumption on the DK side of things? Does the application still run as expected on the BL652 even though the current draw is off. 

An average of 4-5mA sounds incredibly high, and the only thing drawing that amount of current constantly would be the CPU running constantly, so it seems the device doesn't go into sleep mode between advertisements. Simply changing the LF clock source and accuracy should not cause this big of a change in current consumption. However, enabling the DCDC if you don't have the necessary inductors on the DCC pin in your design will likely cause trouble, and might cause a big current draw, but if that's the case, the application shouldn't run as expected either. If you'd like I can do a review of the schematics of your custom board with this module.

Here is a guide on optimizing current consumption on nRF52 designs. Try some of the suggestions there as well to see if you're able to run it as intended.

Best regards,

Simon

[smartventSystems]

Thanks for the prompt reply,

Update: I found out that the BL652 central scanning was drawing the super high 4-5mA. When connected to its peripheral, this drops to around 0.4-0.7mA. This is still much higher than expected though, so I'm sure something is still amiss. 

Yes, the project still runs properly on the BL652 even though current draw is off.

I am measuring the current draw via a multimeter right at the power input lead to my board (which is a direct PCB connection into the power pin for the BL652 chip). The average current consumption on the development kit (using the exact same code and configurations) is around 4uA - 15uA when connected.

I have tried switching the DCDC on and off, and it has no visible impact on current draw.

I have attempted some of the applicable suggestions in the link you provided - I have turned off NRF_LOG_BACKEND_UART already prior, and even ran sd_power_system_off(). Doing this, the current draw on my project became 0.7mA (or around the same as if it were connected) . Doing this on the blinky project running on the BL652 still drew current of 13uA instead of the couple hundred nA.

At this point, I'm assuming that there is some peripheral that is running in the background - would there be any peripherals on the BL652 chips that could be activated while the same configurations do not activate them on the development kit?

Are the GPIO outputs draining power on the BL652 when not configured, not connected, and not powered compared to the pinouts on the development kit?

[smartventSystems]

I was able to find that the uart_init() would draw an extra 350uA or so on the BL652 chip. Is there anything on my code that I could get rid of to reduce power consumption? I thought I already disabled UART logging. Does the UART peripheral usually draw this amount of current? Because I have this active for the development kit, and I'm not getting this much current while it's running there.

 

static void uart_init(void)
{
    uint32_t                     err_code;
    app_uart_comm_params_t const comm_params =
    {
        .rx_pin_no    = RX_PIN_NUMBER,
        .tx_pin_no    = TX_PIN_NUMBER,
        .rts_pin_no   = RTS_PIN_NUMBER,
        .cts_pin_no   = CTS_PIN_NUMBER,
        .flow_control = APP_UART_FLOW_CONTROL_DISABLED,
        .use_parity   = false,
#if defined (UART_PRESENT)
        .baud_rate    = NRF_UART_BAUDRATE_115200
#else
        .baud_rate    = NRF_UARTE_BAUDRATE_115200
#endif
    };

    APP_UART_FIFO_INIT(&comm_params,
                       UART_RX_BUF_SIZE,
                       UART_TX_BUF_SIZE,
                       uart_event_handle,
                       APP_IRQ_PRIORITY_LOWEST,
                       err_code);
    APP_ERROR_CHECK(err_code);
}