A Gentle Power Off for ZEReader: Replacing the Hard Switch with a Latching Power Circuit

With the second revision, the way ZEReader is turned on and off got a massive redesign.
The hard on/off switch in the first revision was dead simple and worked great—with one big flaw from a user’s perspective. You could not recognize if the reader was on or off on the first sight. The old switch just closed or opened the loop with the power supply, and due to the E-Paper display just holding the state, you had no chance to tell.
Besides, there was no possibility at all to implement some kind of graceful shutdown mechanism, which would allow me to save all important state information and show a clear device off indicator.
This situation was totally fine for the very first prototype, but it started to get annoying very soon. A new approach was needed!

Good and Bad Ideas

My very first intention was to search for some kind of IC to solve that problem. The MAX16150, a nanoPower Pushbutton On/Off Controller and Battery Freshness Seal, read like an exact fit for what I was looking for from a pure technical perspective.

However, the fixed shutdown period for the MAX16150, depending on the exact model, is between 8 and 16 seconds. That’s pretty long and not really intuitive for a user.

Besides, this rather simple IC is with around €3.3 just too expensive in relation—but it gave me a conceptual idea of how to continue.

Utilizing a Self-Holding (Latching) Circuit

The solution lies in a self-holding (latching) circuit: a circuit that closes the loop to the power supply when a button is pressed and can then hold itself active afterwards. This can be achieved with just a few simple components.

The central elements are two enhancement-mode MOSFETs (one n-channel and a complementary p-channel one) and two switching elements.

The Falstad CircuitJS Simulator helps to visualize the idea and functionality. You can try out the simulator yourself later in this post, but let’s start with an explanation first.

The Initial Situation (Off State)

The following picture, taken from the CircuitJS simulator, shows the circuitry for the new on/off mechanism in its initial (off) state.

The dashed box represents the microcontroller (MCU), which the self-holding circuit attaches to via two GPIOs. The top connection is a GPIO input, used to record and interpret the physical button input, while the second one, a GPIO output represented as an internal switch, is used to actually control the power flow.

In the pictured initial situation, the hardware button (top left) as well as the internal one (the output GPIO) are open and both MOSFETs are off (blocking). The enhancement-mode p-MOSFET in the top of the picture is blocking because its control voltage \(V_{GS} \approx 0\) (its gate is pulled high). It will become conductive if \(V_{GS}\) gets negative. The enhancement-mode n-MOSFET will conduct on a positive control voltage \(V_{GS}\), which is also \( \approx 0\) right now.

Getting the Microcontroller Started…

Following the well-known pattern from other electronic devices, I’d like the device to start up and shut down again on a long press on the power button. Fortunately, this behavior is perfectly depicted by the shown circuitry.

As long as the user button in the top left area is pressed, current flows via the button and the diode pointing upwards into the microcontroller. This causes the MCU to start up and initialize itself and the peripherals in less than a second.

At the same time, the GPIO input will detect a logical one with a level of \( \sim 2.7 V\), which is limited by the Zener diode for protection, as the input voltage is usually assumed to be \(5 V\).
The \(10 k\Omega\) resistor in parallel is a pull-down to ensure defined logic levels and avoid getting trapped with the Raspberry Pi Pico 2’s E9 Bug.

… And Keep it Running

To keep the device running without the need to keep the button pressed, the GPIO output must be set to high (\(3.3 V\)).

Depending on the desired behaviour, it is up to the application software to decide whether this should take place as soon as the boot up reaches a certain stage or if the input GPIO should additionally be evaluated.

With this output GPIO (represented by the switch down right) set to high, the n-MOSFET in the lower left area becomes conductive (its \(V_{GS}\) got positive). This action pulls the gate line of the p-MOSFET above to ground, making its control voltage \(V_{GS}\) negative. Thus, the p-MOSFET becomes conductive.

The self-holding circuit is now up and driving the microcontroller, independent of the user on/off button press.

Interrupts

As long as the self-holding circuit and thus the device are active, the on/off button becomes a usual interrupt source from the microcontroller’s point of view.

Depending on the intended device behaviour, the software implementation could also listen for common, short button presses and use the button like everyone else.

A Gentle, Software-Defined Shutdown

With the pictured circuitry, shutting off the device means toggling the output GPIO (switch) in the lower right to zero again. When this happens is completely defined by the microcontroller’s software.

To reach the intended behaviour, the ZEReader firmware utilizes Zephyr’s input-longpress infrastructure. This makes the required button press time easily configurable, and a gentle shutdown routine can be started from the longpress callback function.

This allows me to implement a proper shutdown routine, for example, saving the current reading state, showing a logo or some other kind of shutdown screen to make clear the device is off now, or even asking for pressing another button to confirm turning the device off. As long as toggling the output GPIO is the last step, the shutdown behaviour before can be feely defined, matching the target application.

Try out the Simulator!

Time to play around with the circuitry at your own!
Click around in the interactive simulation and observe the behaviour.

But does it also Work in Real-Life?

Sure!

Update 2026-02-01:
The v2 PCB is not finished yet, but circuitry was tested with a simple breadboard setup to verify it and develop the software side..

The v2 PCB works great!
(If you do not introduce software issues between the breadboard testing code and the actual ZEReader firmware…)

A quick check with the oscilloscope helped me check for the expected voltages. The Pi Pico can deal with a surprisingly wide range, but with the E9 bug still active for my board and not trusting the app note stating the inputs are \(5V\) safe, it was better to actually verify the button’s input signal quality and level and measure through the whole setup.

Trace 1: A Failed Latch

This first oscilloscope screenshot shows a single short button press in the circuit’s initial off state (Channel 2, blue). The button press is fine and can be registered, the microcontroller starts its work, but in this case, it was below the configured threshold to start up completely. The microcontroller did not yet set its output GPIO (Channel 1, yellow) to high, thus the self-holding circuit was not activated.

Trace 2: Active Interrupt

The next screenshot pictures the situation with the self-holding circuit already activated. A (short) button press without toggling the controlling output GPIO is completely independent and does not interfere with the power path.

Trace 3: The “Hold-On” Shutdown Behavior

At last, I want to point out to a maybe surprising, but logical behaviour you can see in the following last oscilloscope screenshot, which is also confirmed by the software log screenshot.

With a long button press registered, the controlling GPIO output is toggled as expected (Channel 1, yellow) — but the device does not stop immediately, even if the power off routine is finished (a printed ‘x’ means the software is running).

As long as the on/off button is pressed, the device is still powered through the direct path described above, and thus alive and still running. Only when the button is released, it is actually turned off (and thus no logs are printed anymore).