"OFF" power consumption increase +100µA after firmware change, and does not decrease after roll-back

RE: "OFF" power consumption increase +100µA after firmware change, and does not decrease after roll-back

pdelrot_samea — Wed, 12 Nov 2025 16:39:13 GMT

Well,

Adding this to the overlay file does not harm, but do not solve the problem even after UICR erase ( Working with the nRF52 Series' improved APPROTECT + https://jimmywongiot.com/2019/08/19/manufacturer-storage-data-on-uicr-region/)

&uicr {
nfct-pins-as-gpios;
};

&nfct {
status = "disabled";
};

> nrfjprog.exe -i
<myserialnumber>
> nrfjprog.exe --family NRF52 --recover --snr <myserialnumber>
Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas.
Writing image to disable ap protect.
> nrfjprog.exe --snr 260111492 --memrd 0x1000120c
0x1000120C: FFFFFFFE |....|

The value is the one expected (LSB bit 0 set to 0 as per specification). Current decrease is 15µA.

So then ? Additionally, when the debugger is connected, powered, but not used, current consumption is 50-60µA... and increase when I disconnect the debugger USB cable.
One mistake was to perform the measurement with the debugger connected but unpowered.

With cables disconnected (as in real life), power consumption is as expected : 25µA.

Solution :

take care of UICR and NFCT configuration in the design for the future
note to myself : do not forget power leakage of the debugger !

At least, I learn few newer things today.

Best regards,

Pascal

RE: "OFF" power consumption increase +100µA after firmware change, and does not decrease after roll-back

pdelrot_samea — Wed, 12 Nov 2025 15:09:49 GMT

Hello,

Yes, power consumption verified just before
System OFF sys_poweroff(); : a wake-up pin is used to restart the device
The nRF chip is in OFF mode waiting a wake-up from the host, to restart a BLE advertising or scan BLE devices. A SPI bus is used to control the device. As battery powered product, the power consumption is very important.
Yes, our KConfig/overlay files has been updated for that.

Regarding the power consumption, according data sheet, the closest peripheral for 100µA is the USBD, but nothing is set at all for software, neither in hardware. I didn't found any persistent register.

I made a diff between the device trees generated by the SDK 2.3.0 and 3.1.0.

I found few differences, here are the most important to my eyes, being analysed :

SDK 3.1.0 : rtc, timers are disabled / with SDK 2.3.0 status was "okay". We don't use them intentionally. Such setting seems good to me.
SDK 3.1.0 : clocks hfxo is present, 64MHz value. Our quartz is 32Mhz. I have to verify if hfxo is linked to this oscillator.
SDK 3.1.0 : gpregret1/2 are present. Why not.
SDK 3.1.0 : reg0/1 are present
SDK 3.1.0 : &uicr and &nfct are present

For the last one, I found these lines in '\ncs\v3.1.0\zephyr\soc\nordic\Kconfig'

config NFCT_PINS_AS_GPIOS

Two pins are usually reserved for NFC in SoCs that implement the
NFCT peripheral. This option switches them to normal GPIO mode.
HW enabling happens once in the device lifetime, during the first
system startup. Disabling this option will not switch back these
pins to NFCT mode. Doing this requires UICR erase prior to
flashing device using the image which has this option disabled.
[... instructions for device tree given ...]

EDIT : We don't use this feature. One pin is reserved for a future I2C SLC, the other left open. We didn't managed any configuration yet. We have to keep this NFC feature disabled.

At least, such configuration ticks the box "survives to reflashing and power off". For the power consumption I don't know.

Pascal

RE: "OFF" power consumption increase +100µA after firmware change, and does not decrease after roll-back

Einar Thorsrud — Wed, 12 Nov 2025 13:38:10 GMT

Hi Pascal,

1. It is suprising that running the old firmware you see the same higher current consumption. Did you verify the lower current consumption on the exact same board before, and has there been any hardware modifications or changes in the test setup?

2. When you write OFF mode, which exact mode is this? Is it system OFF low power mode (where a wakup is in form of a reset), or another low power mode?

3. Can you say more about your firmware and hardware (which compoents are enabled in active mode, and what is the intended state in OFFmode)?

4. Regarding regulator-initial-mode in the devicetree that is needed ad regulator mode is now configured in the device tree, but in older SDK versions like 2.3 it was configured in Kconfig. If the device by a mistake is configured to use DCDC and the optional DCDC inductors are not present, the device will fail when attempting to start the DCDC regulator.

Br,

Einar