Power Cycling Safeguard

[ishgum]

Details:

nRF52832

SDK 14.1 with matching SD

Compiling with GCC

I am trying to solve the following problem:

My device is powered by a coin cell (Manganese dioxide). When these cells reach their capacity their internal resistance increases. 

If my device attempts a Bluetooth communication this may cause the battery voltage to dip below the brownout voltage - triggering a system reset.

It is then possible that during startup the device draws too much current and dies again, thereby creating a loop of power cycling which will continue to drain the battery until dead, but also potentially corrupt flash memory in the process.

My current methodology is to somehow keep a count of the number of resets that gets set to zero after startup, if the device resets 5 times without finishing the startup process, kill the startup and go into system off mode.

Unfortunately, no registers are retained on a brownout reset, so I cannot use them to store information on the reset.

I could use flash, but there is a risk of corrupting all of the flash data in the startup sequence as the power could die during initialisation or mid-write.

The solution that seems to be the most elegant is to simply store a variable in RAM, and create a "noinit" section as described here: noinit example

This seems to work for watchdog resets and software resets, but doesn't seem to work for pin resets or brownout resets. On a pin reset (easier to do), the values on reset are pretty consistent, which leads me to believe that some other part of the program that I'm not aware of it writing to that memory?

Are there any other methodologies I could try here? What is the Nordic best practice around this?

[Kenneth]

I would have measured the battery voltage after reset (for instance over a period of 10ms), and if it's below for instance 2.5V go directly to sleep and potentially blink an led at slow interval to inform user that battery is end of life. I don't think adding counter etc. is a good idea after reset, since you won't have any knowledge of time and also that you may have poor connection of battery if user shake the product or while the battery is inserted in the holder etc. which may give odd results I think. You might find this useful:
http://www.low-powerdesign.com/121312-article-extending-battery-life.htm 

Best regards,
Kenneth

[ishgum]

Thanks for your answer Kenneth.

My understanding is that the major problem with these batteries comes from the internal resistance and that it is hard to get a good understanding of the end of life just by measuring the voltage, i.e, you may measure the voltage above 2.5V and then try and start advertising, draw too much current for the battery and trigger a brownout reset. Or is my understanding of this flawed?

[hmolesworth]

You are broadly correct; the trick is to not use the coin cell to power the advertising power burst. The common solution is to use about 100uF low-ESR capacitance across the coin cell such that the coin cell basically trickle-charges the capacitance and the capacitors actually act as the burst power source. Tantalum or electrolytics are no use, they have too much leakage but ceramics work well. If you have a miniature device with no physical space then split the 100uF into 3 x 33uF or similar connected in parallel as they require less headroom.

To measure the residual battery capacity, turn on some internal peripheral or LED which has a (small) known current requirement; measure battery voltage before and during and the difference - or better the decaying voltage - will allow an estimate of capacity for a given temperature to allow a better choice of when to finally give up advertising attempts due to battery exhausted (at that temperature).

If you already have such capacitance (10uF is not enough) the only other option is to use a boost convertor to trickle charge a much higher voltage capacitor, then use that power instead (remember V^2) but of course now you are losing efficiency over the battery lifetime. You can also try using the internal DC-DC instead of the internal LDO to see if you get better results.

[ishgum]

Ok, good to know. We have already added about 47uF of capacitance for that very reason, I wasn't sure if this would just extend the life or whether it would actually be able to prevent the power cycling on startup as described above.

That is quite a good way of measuring residual battery capacity that I haven't actually looked into yet, would the effectiveness of that be reduced by adding a capacitor as mentioned above?

I believe I am already using the internal DC-DC, or more to the point, I have enabled DCDCEN in sdk_config, which I believe automatically switches between DC-DC and LDO when each give their best efficiencies? internal-dcdc-vs-ldo-for-nrf52-series

[hmolesworth]

The decay measurement takes longer with more capacitance, but really it's the rate of change you are looking at so you don't need to decay the voltage for long. 47uF is a little light; I recommend using at least 100uF. Better to measure the decay for characterisation under both LDO and DC-DC operating modes which gives a good indication of how much improvement there is by using one or the other. Clearly with higher battery voltages the DC-DC will be much improved over the LDO, less so at lower battery voltages. I assume there is no external regulator of any kind? It's better not to have one ..

DCDCEN may not be doing what you expect, I would trace the generated code to verify that. I use the following immediately after a reset:

   // DC-DC power supply enable, saves about 100mA at 2.7 volts over using internal LDO regulator
   nrf_power_dcdcen_set(true);

[ishgum]

Wow, I bow to your wisdom. Setting nrf_power_dcdcen knocked about half of the power consumption for the BT radio TX. I had assumed the soft devices used the power driver, and would initialise it with DCDCEN set. 

I'm just about to test residual battery voltage, do you have a recommended way of implementing it, or any example code that I could work from?

You are correct, we don't have any external power regulator.