Unexpected Wakeup from Hibernate Mode via SHPHLD with Rising-Edge Configuration on nPM2100

[vielleicht]

Hi Nordic team,

I'm using the nPM2100 PMIC in my design to power a microcontroller. The microcontroller sets the nPM2100 into Hibernate mode, and a vibration sensor connected to the SHPHLD pin is used to wake the system on movement.

• The vibration sensor is normally closed, pulling SHPHLD to GND (low) during rest.

• The PMIC is configured to wake on a Rising Edge on SHPHLD (via register 0xC2 = 1).

• SHPHLD is internally pulled up.

 Problem:

When the SHPHLD pin is already high before entering Hibernate, the nPM2100 immediately wakes up, even though no edge transition occurred. This seems to contradict the expected edge-based wakeup behavior.

To eliminate external factors:

• I replaced the vibration sensor with a mechanical switch (same logic behavior).

• No bounce or glitches were observed.

• Wakeup occurs immediately if SHPHLD is already high when Hibernate is entered.

Attached you’ll find two charts:

 Figure 1: Shows the SHPHLD wakeup trigger occurring without any edge transition at Hibernate entry (Rising-Edge configuration).

 Figure 2: Same scenario with Falling-Edge configuration (0xC2 = 0) — no false wakeups occur. Behavior is now correct and stable.

This leads me to believe that:

The nPM2100 may internally default to a low reference state for SHPHLD edge detection during Hibernate entry. If the pin is already high, this is interpreted as a Rising Edge, triggering a wakeup immediately.

This behavior is not described in the nPM2100 Product Specification.

 Temporary workaround:

I switched to Falling-Edge detection and inverted the logic. This now works reliably.

---

 My questions:

1. Is this a known behavior or a bug in the Hibernate wakeup edge detection logic?

2. Does the PMIC not properly reference the current SHPHLD state when entering Hibernate?

3. Can this be addressed in firmware, or should Falling-Edge be considered the only reliable mode?

Thanks in advance – let me know if you'd like more test logs or register traces.

Best regards,
Philipp

[Kazi Afroza Sultana]

Hello,

I have some feedback from team. we managed to simulate the scenario.

Cycling between entry and wakeup from hibernate should work after first configuration. We also have checked that hibernatePT which requires reconfiguration everytime after wakeup (it will reload OTP values).

Wakeup event supposed to be edge or level-triggered? SHPHLD pin is synced and debounce filtered, so it is more like level active. If it was already in wakeup condition and then it is not seen any edges, but if it is not in wake-up condition then you might call it edge triggered. 

[vielleicht]

Hello,
thank you for the time you spend on the clarification and for reproducing the behaviour on your side.

Based on your feedback and our own testing, we now understand the SHPHLD wake-up mechanism as follows:

1. The SHPHLD input is synchronized and debounce-filtered.
   This means the pin is sampled and evaluated on its level, not on an asynchronous transition.

2. If the pin is already in the active level when entering Hibernate, the nPM2100 wakes immediately, even though no edge occurred. This confirms that the mechanism is fundamentally level-triggered, not event-driven.

3. If the pin changes level during Hibernate, this may look like an edge-triggered wake-up, but only because the sampled level changed between sampling points — not because an actual edge detector exists.

From this, it becomes clear that the wake-up mechanism is always level-based, and the apparent “edge-triggered” behaviour is just the result of comparing sampled levels.

---

Important implication (our actual problem)

Because no real edge detection is implemented:

• Short pulses can be missed, depending on the sampling and debounce timing.
  In other words: a signal must remain active for a certain minimum duration to be recognized — but the required duration is not documented.

• This also requires reconfiguration before entering Hibernate, otherwise the wake-up condition may not match the actual signal state at the moment of entering Hibernate.

This behaviour is critical for system design and should be reflected in the documentation.

---

Request

Given these findings, the current datasheet wording (“edge-triggered wake-up”) is misleading and suggests true edge/event detection, which is not the case.
To prevent misinterpretation and debugging issues, could you please update or clarify the documentation to explicitly state:

• that SHPHLD wake-up is level-triggered due to synchronization and debounce

• that short pulses may be lost

• that minimum pulse width requirements apply

• and that a fresh configuration may (in some certain cases) be required before entering Hibernate

Thanks again for your support and for considering these corrections.

Best regards,
Philipp

[Kazi Afroza Sultana]

Thanks Philipp. we will try to clarify this mechanism on the next version of Product documentation.