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

[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]

Hi Einar,

I'm certain it is a BOR; the RESETREAS is cleared and also the RTT logging doesn't show any information about another reset. The plot was only a measurement of different capacitors with a known load; it was not the critical battery which created the BOR.

I'm thinking of setting up the power-fail-comparator, and if the voltage gets critical (say about 2V) I'll only sending sporadically the urgent messages. Is there an example of using the POR in Zephyr?

Additionally to the POR I'm decreasing the TX power. Currently I'm using +8dBm. Is there an automatic adaptive way to alter the TX power depending on the RSSI e.g. with good RSSI values I can decrease the TX power one step? Or do I have to program this in my user firmware?

[Einar Thorsrud]

Hi,

I see. There are no official samples of using the power-fail-comparator in the nRF Connect SDK, this is a small code snippet that demonstrate how it can be used (with CONFIG_NRFX_POWER=y added to prj.conf or similar):

#if CONFIG_NRFX_POWER
#include <nrfx_power.h>

void pof_cb(void)
{
	printk("POF event\n");
}

static void pof_enable(void)
{
	nrfx_power_pofwarn_config_t pof_config = {
		.handler = pof_cb, 
		.thr = NRF_POWER_POFTHR_V22,
		.thrvddh = NRF_POWER_POFTHRVDDH_V29
	};

	nrfx_power_pof_init(&pof_config);
	nrfx_power_pof_enable(&pof_config);
}
#endif 

The HCI Power Control sample demonstrate settign the Tx power runtime. You could do it adaptively based on RSSI (and/or battery condition), but that would be up to you. 

[Phobios]

Thanks a lot hmolesworth and Einar with your code examples. Both works fine and helped me a lot.

[Phobios]

 Hi hmolesworth ,

sry I have to dig out the post again, but I've now prepared some Sensors with additional 100µF/6V3 and 47µF/10V ceramic capacitors. I've made some comparison measurements with NRF Power Profiler 2. I'm a little puzzled, cause with the additional capacitors, the current spikes are higher, than without.

Measurement 1: Sensor with 47µF

Measurement 2: Sensor with 2x47µF and 100µF

The really odd thing is: If I meassure the voltage drop, the more capacitors helps (and I've not swaped any measurements, I checked it three times)

Any suggestions?

Thanks and Best Regards,

Phobios

[hmolesworth]

The curves are as expected; pity the PPK-2 doesn't allow voltage measurement, and thence power calculations, which would illustrate why. Current is a don't care here, voltage dip is all that matters as the voltage dip is what causes brownout issues. For a given power burst (typically BLE Tx transmit) higher available current (bigger caps) means lower voltage dip: volts x amps will be similar in both cases, except losses will be higher with the smaller capacitance as more current during the pulse is sourced via the battery resistive internals which is bad for the battery, bad for the planet and reduces anticipated product life.

[hmolesworth]

I should clarify the required PPK2 connections, just in case not obvious. The coin call connects to PPK2 VIN and GND in Ampere Mode with no capacitors on the battery; the extra capacitors should be connected between VOUT and GND as the required measurement is just the battery current, not the battery current plus extra capacitor current. I wonder if in the measurements shown above the capacitors are instead on battery and VIN.