Hibernate keeps resetting on Boron

I have a project that's been working fine. It gets woken up by an external event, does a Publish, then hibernates for days until the next event.

I did an update to it and now every time the device enters a hibernate state it immediately wakes up and starts up again. The update had nothing to do with the hibernate logic.

After a lot of testing and hair pulling, I swapped in another Boron (LTE BRN402, same type of Boron) and all is working fine on that one.

Any ideas why the original Boron's hibernate stopped working? I may have done a firmware update, but the firmware levels on both Borons is the same.


What sleep options are you using? I realize you said all, but the wake options do matter for the possible reasons.

Do you have anything physically connected to the RST pin, like an external switch?

This is the code I use to put the device in hibernate mode:

void Hibernate() {
    SystemSleepConfiguration config;
    config.mode(SystemSleepMode::HIBERNATE).gpio(WakePin, FALLING);

WakePin is D8, and it is held high via a 330K resistor. The external even triggers a switch that brings D8 to GND.

Nothing is connected to the RST pin.


330K is a very high resistance for a pull-up on a physical switch. A more typical value would be 10K, or even 2.2K.

I would concentrate on that angle; it's probably not a software issue, and mostly just luck whether it works or not, and swapping the device just changed your luck rather than actually solving the problem. But this is only a guess.

There's one other possibility: HIBERNATE behaves differently than ULTRA_LOW_POWER and STOP. In HIBERNATE on nRF52, when a level-change interrupt (FALLING, in your case), it's not actually handled as a level-change in the MCU hardware because it's not supported by the hardware. In HIBERNATE only, if the wake pin is already in trigger (LOW, in your case), the device will immediately wake again, even though a level transition did not occur. This doesn't happen in ULP or STOP.

1 Like

Once I saw the undesired behavior during testing, the wakepin was always held high by the resistor - there was no switch to even possibly bring it low. And Boron #1 continually hibernated and immediately restarted. Boron #2 did not exhibit that bad behavior.

I will try a lower value resistor in case that might solve it.