[nRF9160] How to differente between brown-out (BOR) vs initial power-up (POR) resets

[SMADEr]

Dear All,

We have a custom design with a nRF9160 powered by Lithium primary batteries.

When batteries end of life is coming or sometimes when harsh environmental operating conditions occurs (high/low temperatures, weak network conditions, etc.), battery voltage may drop below 2.8VDC when modem is powered-on (high peak current not handled by bulk capacitors).

We can see in the last datasheet, BOR and POR voltage thresholds:

And also the reset behavior between POR and BOR, where RESETREAS register would help us to differentiate these 2 sources of reset:

Then take a look to the RESETREAS register:

There's no flag helping to differentiate between BOR and POR.

Are we missing something?

What could be a workaround to differentiate at Nordic's power-up if it has been caused by a reset or a nominal power-on?

Many of our devices on the field show unpredictable behavior because of these resets, like entering in a rebooting loop which could last several minutes (which accelerates discharge of battery)

We'd like to find a FW workaround, any advice would be kindly appreciated.

Regards

[Achim Kraus]

SMADEr said:

There's no flag helping to differentiate between BOR and POR.

Are we missing something?

In my opinion, that's more an issue of the zephyr API implementation.

For the nRF9160, a POR is simply indicated by no flags, all other reasons have flags.

Calling "hwinfo_get_reset_cause(&cause)" returns therefore 0 as cause  (no flags), but zephyr would have a RESET_POR flag, which then causes irritation. As work-around I use inject RESET_POR for cause 0 .

[SMADEr]

Thanks for your reply, but it doesn't help us so much. I'm not really sure this is due to zephyr API implementation, since it seems that a flag is missing in RESETREAS register.

But, what we need is to differentiate a POR (ie. very first start up of the nordic IC, from the time its power supply has been enabled), from a BOR (ie. next starts up of the nordic IC, caused by a reset since power supply has reached the BOR level, 2.8VDC).

Today, we're unable to differentiate these 2 events, which are very different in our use case, and need to be handled by the firmware differently

[Achim Kraus]

POR is the case, where no flag is set.

Other MCU my handle that different, but here it's simple, no flag => POR.

All other reset reasons are indicated by a flag.

Edited:

I get it, sorry.

Yes, there is not only no flag for POR, there is also no flag for BOR.

If that's an hardware limitation, I guess, it can't be fixed in the near time (if at all).

[Charlie]

Hi Sébastien,

Thanks for reaching us for your questions.

We have a custom design with a nRF9160 powered by Lithium primary batteries.

When batteries end of life is coming or sometimes when harsh environmental operating conditions occurs (high/low temperatures, weak network conditions, etc.), battery voltage may drop below 2.8VDC when modem is powered-on (high peak current not handled by bulk capacitors).

Not sure if you mean your nRF9160 is directly connected to a lithium primary battery. If so, please consider improving your circuit to enhance power supply stability. You can refer to the Thingy91X design as a reference.

If needed, feel free to generate a private ticket for our free schematic and PCB layout review service.

There's no flag helping to differentiate between BOR and POR.

Are we missing something?

The POR and BOR are generated directly by the power supply supervisor and are not reflected in the RESETREAS register. Since both BOR and POR behave the same way, the RESETREAS register will be set to 0 in either case. Therefore, the datasheet's RESET behavior section should indicate that both BOR and POR will result in a RESETREAS register value of 0. I will report this potential mistake to our chip development team for confirmation.

Power supply monitoring

What could be a workaround to differentiate at Nordic's power-up if it has been caused by a reset or a nominal power-on?

 You can consider to use AT%XPOFWARN to monitor the brownout reset caused by BATTERY LOW. 

Best regards,
Charlie

[SMADEr]

Nordic is powered from a Buck-Boost DC-DC power supply, input of the DC-DC is the Lithium Battery.

We are aware that our power supply is not strong enough in case of end-of-battery life (increasing internal DC resistance / lower battery voltage when surge current are required by modem), and in case of weak network conditions, when modem need require high peak current when reaching for network connexion, but generally POR & BOR flasgs allow to handle the case in firmware to adapt device behabior.

Next HW release of our device will improve the power supply behavior in such cases, but for now, we have thousands of devices on the field which need to be FW upgraded to avoid loop rebooting.

Thanks for the AT%XPOFWARN cmd, may be it will allow us to avoid reboot if the modem could itself sets off in case of low voltage detection. We will try it.

Regards