Voltage drop triggers BOR reset; MCU occasionally completely freezes

[Phobios]

Hi,

I'm facing a critical issue with our sensor's power setup and would really appreciate any insights or suggestions.

Our sensor is currently using a CR2477 battery, and I'm running into problems due to the load resistance of the battery. When transmitting data, especially after switching from PHY_1M to PHY_CODED_S8, the battery voltage drops enough to trigger the Brown Out Reset (BOR), which then resets the sensor. I noticed this specifically with PHY_CODED_S8 since the transmission takes longer, causing a larger voltage drop.

Occasionally, the sensor also completely hangs—even after the voltage recovers back to 3V again. From my understanding, this seems to be expected behavior with the nRF52 when experiencing a brownout, as only a full power cycle can bring it back online - why is that so and can I prevent this?

Has anyone experienced similar issues or found software and/or hardware solutions to prevent these resets? I’d be especially interested in any software adjustments to handle the BOR more gracefully or hardware tips for improving power stability with high load resistance batteries in future versions of the sensor.

Currently I'm powering directly via the CR2477 to VDD and VDDHV with a 47µF and a 4.7µF capacitor (and of course the standard 100nF on each power input)
DCDC on µC is enabled

Setup:
NRF52840, NCS2.6.1, Zephyr

Thanks in advance for any advice!

Best Regards,
Phobios

[hmolesworth]

Coin cells typically cause the issues noted; trick is to first treat the coin cell as a trickle charger to bulk capacitance (ie not the primary power source) and second to measure the remaining capacity prior to a current burst such as BLE data transmission. Lithium requires rest prior to use after a burst; capacity measurement can provide an indication of the remaining capacity at a given time. BLE transmissions use the bulk capacitance as a power source, not the coin cell. 47uF is insufficient; try 150uF (3 x 47uF) and use a low BOR  value. Coin cells after a pulse discharge recover voltage slowly, and this violates the VDD risetime for correct reset operation as the reset is not a simple DC threshold but an AC-coupled threshold so slow rise times leads to indeterminate states ie hangup.

See my comments on these postings:

power-cycling-safeguard 

creating-a-load-on-a-battery

using-cr2032-in-freezing-temps

nrf52840-hanging-up

issues-with-power-on-reset-in-nrf52840

[Phobios]

Hi hmolesworth,

thank you very much for your detailed answer. I've made a test with some ceramic capacitors. This image shows two measurements where I enable a load of about 7mA (440Ohm @3V) for about 5ms. The RED voltage is without any capacitor, the BLUE with 2x47µF. 

I see an improvement, but I'm a little worried, that the voltage drop is still that high, I hoped for a way better buffering. Are the values reasonable? Show I add way more capacitors; I'm worried that over time the coin cell load resistance will get higher and then also the voltage drop - and I really want to use all the 1000mAh from the CR2477

I've also measured CR2477 from different companies and got better results with some. Have you some experience which manufacturer has good coin cell batteries?

Thank you very much,
Phobios

[hmolesworth]

Ceramic capacitors when used as bulk capacitance require a voltage rating 2 x the actual coin cell voltage, so a rating of at least 6 volts in this case (discussed elsewhere); lower ceramic capacitor voltage ratings reduce the effective storage capacitance. BLE transmission is fine with VDD pulsed low to as low as 1.7 volts, however the Brownout Reset activates at 1.7 volts so best to set a Power Fail warning (then force Radio etc off and immediate low-power mode) at (say) 2.0 volts until the coin cell has sufficient rest to recover.

The Brownout detector is a DC level; the PowerOn reset is not which means slow VDD rise times from a low voltage near 0 may not reset properly which leaves the nRF52840 unresponsive. Avoid a Brownout reset or in-use partial poweron reset at all costs; be severe with Powerfail detection and force low power. On power-up or recovery from low power detection measure the coin cell status by applying a known load for a brief period and monitor the decay in Vbatt to ensure the coin cell has sufficiently recovered before allowing normal operation.

Coin cell capacity is notoriously variable; avoid low-cost equivalents, if possible use "Medical" versions. Ideally verify operation with a few manufacturers and specify pulsed operation when asked for application data.

The nRF52840 should of course have DC-DC enabled and although the nRF52840 works fine down to (say) 1.8 volts note that other attached circuits don't; for example LEDs will flicker on BLE transmission unless driven by a separate boost regulator or simple voltage-doubler and monitor circuit. Most external peripheral analogue circuits work fine to 1.8V but some don't, and in any case voltage dips alias into analogue readings. BLE packets transmitted 8 times a second will alias into a 8Hz waveform on that nice otherwise clean brain wave. Fix by separating the voltage sources of Radio and external analogue, typically with Maxim Ideal Diode with separate bulk capacitance for each. Analogue VDD can be taken from the OUT pin with local bulk capacitance. nRF52840 and coin cell with bulk capacitance are on MAX40203 VDD pin.

The Ideal Diode allows the local bulk capacitance to hold up the external analogue supply when the nRF52840 VDD dips down to a much lower voltage.

I posted some more here:

weird-issue-observed-with-nrf52832

functionality-if-vdd-does-not-go-to-0v-when-powered-down

[Einar Thorsrud]

Hi,

If I read the plot you had correctly, the voltage only drops down to 2.735, so I do not see how this could be a brown out reset. Did you read the RESETREAS register and confirm that it was a BOR or power-on reset (in both cases the register will be cleared), or do you just see a reset and assumed a BOR?

If you just see a reset, the first thing I would suspect was some form of firmware error, where the error handler triggers a soft reset, which is the default behaviour (and particularily usefull in release builds in order to recover from unhandled errors). I suggest starting with basic debugging to see what is happening. If you have loggign enabled, you can check the log. You can also add CONFIG_RESET_ON_FATAL_ERROR=n in your prj.conf to not get a reset when an error has occured).

[Phobios]

Thanks again, you rly are an expert on this topic :)

The way you measure the remaining capacitance of batteries is a new approach for me, but a very promising one. Up to this moment I was only measuring voltage at no load; I know it is not exact but I though the last week before the battery dies it will slowly drop from 3V to 0 and I can alert the user in advance.

If I measure the voltage drop and its decay rate in time; which drop and rate will be which capacitance. How can I say the battery is at 100%, 75%, 60%, 50%, ... and so on? Do I have to pre-measure each manufacturer battery and create a comparison sheet, or is there an overall rule?

Also do you have an example code on how to measure the decay rate with an ADC?