[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).