Sudden Battery Drain and Unexpected Current Spikes in nRF52832 Device (nRF5 SDK 17.0.2)

[Madhav]

Hello,

We are investigating a sudden battery drain issue in our nRF52832-based wireless product. During power profiling, we noticed unexpected current glitches (please see attached image) 

Image 1 shows power consumption in idle mode where as image 2 shows active mode to sleep mode transition.

                       

It appear that current glitches are prevent the system from entering proper sleep mode, causing higher than expected idle current and some times faster battery depletion.

System Details

SoC / Module: nRF52832 (Holyiot Module — datasheet link)

SDK Version: nRF5_SDK_17.0.2_d674dde

SoftDevice: S132 v7.2.0

Compiler / IDE: Segger Embedded Studio

Power Measurement Tool: Nordic Power Profiler Kit II

System Functionality

The device transmits event data over BLE, then enters sleep mode using sd_power_system_off().
Most of the time it should remain in sleep (expected consumption ~1–5 µA).
When active, it draws 5–10 mA for about 50–100 ms (BLE advertising + sensor readout), then returns to sleep.

Problem Observed

Some devices behave as expected initially. After a few BLE transmissions or wake cycles, current consumption suddenly increases to 1–2 mA continuously, and in some cases up to 3–5 mA, even when the device is supposed to be sleeping. Once this happens, the current never returns to µA-level sleep until reset. The issue is intermittent and not reproducible across all units.

As Attached screenshot of the current consumption waveform showing the irregular spikes and elevated idle current.

Power Management Implementation

We are using the standard SDK power management sequence:

sd_app_evt_wait();
// or alternatively
__WFE();
__SEV();
__WFE();

BLE stack is initialized using nrf_sdh_enable_request() and advertising handled by ble_advertising_start().

Peripherals used:

GPIO (Buzzer + button + LEDs)

I2C (sensor)

RTC (timestamp)

PWM ( Buzzer + LED)

All peripherals are explicitly uninitialized before entering sleep (via nrf_drv_*_uninit()).

No SoftDevice assert or error reported during operation.

Debugging Done So Far

Verified that sd_power_system_off() is being called successfully.

Checked that no GPIOs are left floating or driving load.

Disabled logging (UART) and confirmed no change in behavior.

Checked clock sources: using LFCLK from internal RC.

Tested multiple boards from the same batch — issue occurs randomly on some units.

Request for Support

Could you please advise:

Possible reasons for residual current in the 1–5 mA range during sleep (e.g., SoftDevice state, peripherals not fully off, HFCLK not released, etc.)?

Recommended way to confirm if system has truly entered SYSTEM_OFF state while SoftDevice is enabled?

Any known issues or errata related to sd_power_system_off() or BLE advertising stopping in SDK 17.0.2?

Any additional traces or logging you recommend capturing to pinpoint the source of current spikes?

Attachments:

Screenshot of current consumption waveform (Power Profiler Kit II)

Thank you in advance for your help and insights!

Best regards,

Madhav Lohar

[Einar Thorsrud]

Hi Madhav,

We have looked at this but are not able to match your description with 1-5 mA current during sleep to what we see in the plots. Can you please share plots that show more detail, and clarify at which point in which plots we see the different states (bot active state, epxected sleep state, and exessive sleep current)? It owuld also be good to use the selection tool of the power profiler so that we see the average current for these states only and can compare (so the problematic idle current compared to expected).

That said, if the additional curent consumption was in the order of 0.3-1 mA, that could be explaind by for instance some peripherals requesting the HF clock on during sleep for some reason. When you write up to 5 mA, so you then mean peak current or average during the problematic time? The PPK is not very good at showing short peaks, so we should focus on the average current in idle.

[Madhav]

Hi Einar Thorsrud,

Thank you for your quick response.

Due to uncertain behaviour of this problem it might take some time to get plot of device consuming more current.

I missed one point to share is that. When a device starts consuming more current then it will consume same amount of current (approximate 1-5m Amp) even if the battery was removed and reinserted (Device restarted).

[Einar Thorsrud]

Hi,

Madhav said:

Due to uncertain behaviour of this problem it might take some time to get plot of device consuming more current.

I understand. I look foward to seeing the plots when you get them along with detailed explanation of what they show.

Madhav said:

I missed one point to share is that. When a device starts consuming more current then it will consume same amount of current (approximate 1-5m Amp) even if the battery was removed and reinserted (Device restarted).

This is interesting, and not expected. Can you share the schematics of your design and explain a bit more generic about it? Are there other components on the board that is expected to draw significant amount of current, and can there be physical factors that remain the same after a power cycling (removing and re-inserting battery)?