nRF52 Power-fail Comparator expected current consumption

[Sydney]

Our nRF52832-based board is powered by a coin cell battery, and spikes in current can cause the voltage to drop. This is okay early in the battery's discharge curve, but as the battery ages, this gets dangerous and will eventually cause brown-outs. So I looked into the power-fail comparator feature, which seemed really promising. The hope was that I could use the power-fail warning event to detect a rapidly dropping voltage in time to abandon the activity that caused the current spike (and voltage drop). However, I noticed on page 81 of the nRF52832 product spec, it says this:

To save power, the power-fail comparator is not active in System OFF or in System ON when HFCLK is not running.

Obviously since our product is battery powered, we are not running HFCLK the vast majority of the time. I was discouraged, but I figured I could enable the feature when I'm about to begin a risky action and then disable it again once that action is complete. But first I started by enabling the feature at boot and leaving it enabled all the time just to test how well it works. It seemed promising, so I checked the current consumption. To my surprise, I don't think I'm seeing any additional current when the power-fail warning is enabled (using sd_power_pof_enable() and sd_power_pof_threshold_set()). With the Nordic PPK, I measure about 8-9uA when waiting for events between BLE advertisements regardless of the power-fail comparator state, which is about what I expect for this board.

So I guess my question is- why does this work? Shouldn't this feature result in increased current consumption? What am I missing? This seems like good news but I'm worried about relying on this if it's unexpected.

I'm running SDK15.2 and S132, if that matters.

[Simonr]

Hi

Even if you call these functions, they still just enable the power-fail comparator and it won't "kick in" until the HFCLK is started by your application. This is mentioned in its electrical specification. See footnote 8 here.

If you'd like to ensure a safe shutdown from IDLE mode when the HF clock is turned off, please check out the Low power comparator instead, as it consumes less power and can be used to compare the input voltage against a reference voltage like the power-fail comparator as well.

Best regards,

Simon

[Sydney]

After I posted this, I started coming to this realization. I think in all my test scenarios, HFCLK just happened to be running for other reasons, which made it look like the power-fail comparator was generating the warning event even though I thought my board was in idle. For example, one way I tested was by dialing down the voltage on my bench top power supply and verifying via GPIO that the event was being triggered. But I realized that HFCLK was probably enabling periodically for advertisements, which must've been giving the power-fail comparator an opportunity to generate the event. I've since confirmed that a more sudden power loss, like disconnecting power instead of turning the knob, does not generate the power-fail warning event.

Because my potentially-risky high power events are relatively infrequent and short in duration, I can live with the added current required by keeping HFCLK active. So I think I just need a good way to enable HFCLK just before these risky events start and then disable it again after the risky event ends (typically 2-3 seconds later). It looks like I can do this with sd_power_mode_set() to switch between NRF_POWER_MODE_CONSTLAT and NRF_POWER_MODE_LOWPWR as needed. Besides the additional current, are there any concerns with this approach?

I considered using the low power comparator, but I don't have a good external voltage to use as a reference, and the internal references are all proportional to the input voltage, which is what I need to monitor.

Thanks.

[Simonr]

Hi again

If your "risky events" don't start/enable the HFCLK already, it should be fine using sd_power_mode_set() to do so as long as you don't mind the additional current consumption. There shouldn't be any other concerns regarding this approach, so feel free to do so, as I can see that you don't have a good way to implement the low power comp.

Best of luck and regards!

Simon