RE: How to minimize power consumption during power failure while RTC is on

Stian Røed Hafskjold — Sun, 19 Jul 2020 17:35:03 GMT

Hi,

[quote user=""]From the hardware side, is it ok to just feed the nRF52840 through a diode to the pins VDDH and VDD with 3.3V and connect a super capacitor though a resistor?[/quote]

In theory, yes. (Not sure why you need to connect it through a resistor?) But you will have to do some calculations and testing of course.

One thing to be aware of is that if you cut the power to the rest of the circuit, the GPIOs on the nRF52 must not be set to high output voltage as you will most likely power the rest of the circuit through the GPIOs. Set all the GPIOs to disconnected input (0x2) to prevent leakage.

[quote user=""]From the software side when I detect the power failure signal, what steps do I have to take to minimize power consumption while RTC still runs?[/quote]

In general, it is normal to keep the code in the lowest power state no matter if there is a power failure signal received or not. The softdevice examples in the SDK (which need the RTC to run) are already in the lowest power state between the BLE events. Of course there are some pitfalls you should be aware of, but my point is that these should be avoided in any application, regardless if it's a lower power application or not. And the code in the SDK takes care of this already.

Are you going to use the SDK and softdevice?

[quote user=""] I already read that I have to switch off all peripherals such as UART and RADIO and then use WFI/WFE instructions. [/quote]

Yes, it's important to switch of any UART transmission. The RADIO is typically not controlled by the user, since you need a complex stack to operate the RADIO. This stack should already be power optimized (like the BLE softdevice).

WFE should be called whenever the CPU is not doing any thing. The way you normally solve this is to put WFE in the main loop. And just use interrupts to do the different tasks. After the tasks are done, the chip returns to the WFE in the main loop. The softdevice and most of the code in the SDK are designed this way.

[quote user=""]Do I have to change the POWER configuration, for example switch from DC/DC to LDO in REG1? [/quote]

No. The POWER peripheral/regulator is automatically controlled. You just enable (or not enable) DCDC, based on if your design has DCDC components or not, and the the regulator will automatically switch between ULP (Ultra Low Power) mode and DCDC/LDO

[quote user=""]Does the CLOCK need some configuration to ensure the 64MHz clock is switched off?[/quote]

No. The HF clock is automatically controlled. You can however start the HF crystal manually if you need a more accurate clock. And then the HF crystal has to be switched off manually again before entering sleep. But usually you just use the internal HF clock which is automatically controlled.

[quote user=""]Do I understand it correctly to use the ION_RAMON_GPIOTEPORT mode form the Sleep table (System ON, full 256 kB RAM retention, wake on GPIOTE PORT event) and can even lower power consumption by retaining only some of the RAM.[/quote]

You mention that you need the RTC to run, so then the correct number will be the ION_RAMON_RTC.

I_{ON_RAMON_RTC}

System ON, full 256 kB RAM retention, wake on RTC (running from LFRC clock)

3.16

µA

You can disable parts of the RAM if you want, but usually this is not something that is done during run-time. I would check how much RAM you need and then disable the blocks you don't need in the beginning of main (and adjust the linker script accordingly).

Just a final though. If the device is not going to be functional in this "power failure" mode anyways (because if you do anything it will run out of power), it's maybe better to design the code so that it survives a power failure. I'm thinking about writing the critical configuration data to flash, and just load this data back when the device is reset. This way I think it's more robust to failures in general. There might be other reset reasons than power failures.