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

[pdelrot_samea]

Bonjour,

We are working on a firmware upgrade for our product based on a nRF52833.

1. With the previous firmware, compiled with SDK 2.3.0, when the board was OFF, the power consumption was about 20-30µA
2. We work a bit to reach SDK 3.1.0 and update ZephyrRTOS ; and add few features similar to the others we designed
3. The new firmware is functionnal
4. **Except** the power consumption. Now, in OFF mode, the power consumption is about 120µA

I first though we missed something when doing SDK upgrades and configuration.

1. So I flashed the initial firmware for confirmation
2. Surprize !  The power consumption in OFF mode still increased to 120µA

This increased power consumption survives to power ON/OFF cycle, reflashing, memory erasing.

Question : which kind of parameter, OTP register or what so ever could cause this ?

We had to add this in an overlay file ONLY for SDK 3.1.0 ; if not present, the component was not programmable anymore.

&reg1{
    regulator-initial-mode=<NRF5X_REG_MODE_LDO>;    // valeur initiale <NRF5X_REG_MODE_DCDC>
};

But I suppose such setting is 

Thanks for suggestions or help ! I'll dig in the docs this afternoon

Best regards,

Pascal

[Einar Thorsrud]

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

[pdelrot_samea]

Hello,

1. Yes, power consumption verified just before
2. System OFF    sys_poweroff(); : a wake-up pin is used to restart the device
3. 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.
4. 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

[pdelrot_samea]

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