Soft Power Switch Circuit for Battery-Powered Devices

Alternative to Toggle Switch Uses an ATtiny10 MCU

The battery in a battery-powered CPU system typically is activated with a toggle switch. In this article, Michael explains how he overcame the limitations of toggle switches by creating a solution that allows a device to be turned on and off using a simple, momentary push button. Additionally, the CPU system, itself, can control the power, making the solution compact, efficient, and inexpensive to construct.

• The CPU system cannot turn off the power when the battery is running low.
• The CPU system cannot automatically turn on the battery during charging.
• The toggle switch occupies space and cannot be repurposed by the system CPU.

For years, I searched for a solution to address these issues. While some commercial products include this functionality, I was unable to find a readily available, comprehensive solution. Partial solutions exist for individual problems, but none resolved all the challenges.

In this article, I describe the custom solution I developed. It effectively addresses the issues mentioned above, while remaining small, efficient, and inexpensive to implement.

FEATURES

Before we dive into the solution, let’s look at an outline of the required features. For clarity, everything that needs to be powered on and off—such as the system CPU, charger, and so on—is referred to as the “system.” The component that controls power on and off is called the “power solution” (see Figure 1). The power solution must provide six features:

Push Button Control: A push button that can be pressed for a few seconds to turn the power to the system on and off. Power off is also used in case the system CPU is stuck and needs a reset.

System-Controlled Power: The system must be able to turn the power on and off programmatically. Power on is used during charging. (The system is powered by the USB but needs access to the battery to charge it.) Power off is used when the battery is running low, to protect the battery; but it can also be used if the device is idle for a certain amount of time.

Shared Push Button: The push button’s state must be readable by the system for other purposes, such as configuration. This enables the power solution and system to share the same physical button, saving space and components.

Minimal Standby Power: In off mode, the power solution must not drain the battery, keeping the standby power for the power solution alone lower than the battery’s self-discharge rate.

Battery Compatibility: The power solution must operate directly from the battery without any regulator, since regulators will drain the battery. It must support a wide voltage range to accommodate the typical Li-ion battery range of 2.5V to 4.2V.

Compact and Cost Effective Design: The power solution must have a small footprint, making it easy to integrate into compact designs. Additionally, it must be inexpensive, ensuring its cost is negligible compared to the overall system cost.

DESIGN

The power solution utilizes a tiny CPU, a p-channel field-effect transistor (pFET), a resistor, and a push button, as depicted in Figure 2. The power “switch” that transitions battery power to the system is a pFET, which is managed by the power CPU. It is important to select a pFET capable of handling the system’s power requirements. In this example, the SI2305, a SOT23-3 device capable of handling up to 4A, has been chosen, making it suitable for most battery-powered systems.

The push button connects directly to the power CPU, using an internal pull-up resistor. However, the system must also be able to monitor the button’s state. This introduces a challenge, because the button then must span two different power domains. The power CPU operates in the battery power domain, with logic levels up to 4.2V, while the system’s power domain typically operates at 3.3V or lower. Directly connecting the button to a system CPU I/O pin would force the pin to 4.2V, potentially damaging it.

To address this, the button state is echoed on another pin of the power CPU. When the button is pressed, the power CPU outputs LOW; when the button is released, the pin is tri-stated. The system CPU must use an internal pull-up resistor on its input pin, thereby controlling the HIGH logic level. This approach ensures the power solution adapts to the system CPU’s power domain (see Figure 3).

Additionally, the system CPU can manage power on and off using the CPU request pin. This pin requires an external pull-down resistor to ensure a defined logic LOW level when the system CPU is powered down.

STATE MACHINE

The core functionality of the power CPU firmware is implemented using a state machine, as illustrated in Figure 4.

When the power CPU exits reset, it begins in STATE_OFF. If no activity occurs, the CPU transitions to “STATE_ON_OFF” after a 10-second timeout, and then to “STATE_SLEEP” mode after an additional 3 seconds.

When the button is pressed for more than 1 second, the power CPU wakes up, switches to STATE_OFF, and turns on the system power. It remains in this state until the system CPU sets the CPU request signal to HIGH. This transition is necessary, because the system CPU’s ability to set the request signal HIGH is the mechanism for later requesting power off. Once the request signal is HIGH, the power CPU transitions to STATE_ON and remains there until a power-off request is made.

If the button is pressed for more than 4 seconds or the system CPU requests power off, the power CPU turns off the system power and moves to STATE_ON_OFF. In this state, it waits for 3 seconds to ensure the system has powered down fully before entering STATE_SLEEP. The 3-second delay prevents power-down noise on the system CPU request pin from causing unintended behavior.

When the system CPU requests power on for activities such as charging, the power CPU wakes up, connects the battery to the system, and transitions to STATE_ON.

While in STATE_ON, the power CPU echoes the button state to the system CPU. This allows the system CPU to read the button state and use it for configuration or other purposes.

This state machine design ensures efficient power management and reliable communication between the power and system CPUs.

POWER CPU FIRMWARE

This solution is designed with an ATtiny low-power microcontroller with the smallest footprint. There exist four nearly identical models: ATtiny4, ATtiny5, ATtiny9, and ATtiny10. All these devices feature four I/O pins and 32 bytes of RAM, and differ only in flash memory capacity. ATtiny4/5 have 512 bytes, whereas ATtiny9/10 offer 1,024 bytes. They are available in two package options, including the SOT23-6 (3x3mm), which can be hand soldered. These devices operate within a voltage range of 1.8V to 5.5V, meeting the project’s requirements. For low-quantity purchases, all models are priced similarly so for development, I chose the ATtiny10 due to its larger flash size, though the code is compatible across all four devices.

The code is written in bare-metal C, with no room for unnecessary overhead. This approach requires manually programming all aspects, including CPU initialization, timer configuration, and more. The initialization code is given in Listing 1. Instead of providing a detailed walk-through of the code, I’ll highlight key challenges addressed during development.

During initialization, all I/O pins are configured, and the state machine is implemented in function PollState().

A hardware timer (Timer 0) is configured as a counter running at 16 counts per millisecond. A custom delay function uses this counter to measure delays in milliseconds, supporting the state machine’s timing requirements.

When the system is powered off, the CPU enters power-down mode, consuming approximately 100nA as per the datasheet [1]. Achieving this minimal power usage is one of the primary challenges. By default, power-down mode consumes more power due to unnecessary subsystems still running. These are disabled during CPU initialization to meet the ultra-low power requirement.

The power button connects to a CPU pin with an internal pull-up resistor, eliminating the need for an external resistor. The CPU is programmed to wake up from power-down mode on a pin-change event on either the button pin or the CPU request pin. However, this generates an unwanted interrupt, which is handled by a dummy interrupt handler.

Upon waking, the CPU performs a reset to clear any potential memory leaks or errors. This ensures the system always starts in a clean state, preventing long-term failures. The reset is triggered by enabling the watchdog timer, which automatically resets the CPU after a maximum of 16ms.

ISP PROGRAMMING

The device needs to be programmed before it can be used, and in “normal” cases, this would be done by using a programmer with a socket that supports the device.

However, due to the device’s small size, finding a suitable socket can be challenging. It is possible to buy a programmer and then buy a special socket adaptor that fits the selected device, but it gets expensive. Instead, I have chosen to use a programmer called an ISP (in-system programming) that can program the device on the PCB, I used an AVRISP MKII, which I already had. There exist others (newer) that also will work, and in some cases, have more features. There are, however, a few challenges when using an ISP approach. First, the ISP needs a 6-pin connector to the PCB to program the device; it can be a simple edge connector or a physical pin row. I used the edge connector for the evaluation board that is described in the next section.

Second, The programming voltage needs to be 5V. This will typically require that the power CPU is programmed before the system is connected (soldered); otherwise, the system will get 5V on the shared I/O pins, which it most likely could not survive. If the board is hand soldered, this is not a big deal. Just solder the power CPU first, then program it, and then solder the rest of the components. It is not expected that the power CPU should ever be updated.

The power CPU has only four I/O pins, all of which are used. During programming, the programmer needs to reset the CPU, which conflicts with one of these pins. To resolve this, program the CPU first, and then program the reset fuse to disable the reset functionality of the reset pin. This converts the reset pin into a regular I/O pin. However, disabling the reset pin means the CPU can no longer be reprogrammed. Therefore, test the code thoroughly before setting this fuse. Although some programmers can reverse this fuse, it is often cheaper to replace the CPU and solder a new one.

The code is compiled using Microchip Studio, because it supports the AVRISP MKII programmer. If a newer programmer is used, Microchip offers additional software options. The summary of the programming workflow includes.

• Select the actual CPU variant.
• Build everything (compile and link everything together).
• Attach the programmer to the power CPU and ensure the CPU is powered with 5V, since the programmer does not supply power.
• Program the file to the CPU’s flash memory. Then, test that everything is working as expected.
• Once the code is verified, program the reset fuse (RSTDISBL) to convert the reset pin into an I/O pin (used for button echo functionality). Keep in mind that this step disables further programming of the device.
• Disconnect the programmer from the power CPU. Now the power solution is ready for use.

EVALUATION BOARD

Before integrating the power solution into a final product, it must first be developed and thoroughly tested. To achieve this, I needed a platform tailored for development and testing that would allow all features to be evaluated while still permitting CPU updates.

The ATtiny10, described earlier, is unsuitable for this purpose, because its button echo feature cannot be tested without permanently disabling further programming. Instead, I opted to use an ATtiny13 for development and testing. The ATtiny13 is similar to the ATtiny10 but offers six I/O pins, enabling comprehensive testing of all features without the need to disable programming.

When the test is complete, it is also useful to test the final implementation on the ATtiny10, and specifically test that the special fuse programming is working. For that purpose, I built an evaluation board, that supports ATtiny4/5/9/10 and ATtiny13 devices and has hardware to test all features. It also has pads to connect a full system to it, for a more realistic test.

The board schematic is shown in Figure 5. It has support for the power CPU with two different footprints and two different edge connectors for programming the CPUs. It is only possible to mount one of the CPUs on each board, which can then be programmed using the associated edge connector. It is possible to mount two pFET (in parallel), just in case more current is needed, though one is typically enough.

The board has three special test features:

• An LED (D1) that indicates if the power to the system is on.
• A button and an LED (D2) on the button echo signal, to see that the button echo feature is working.
• A switch to emulate the CPU request signal.

The evaluation board is shown in Figure 6. The plot files for PCB production can be found on the Circuit Cellar Article Materials and Resources webpage.

I began by writing the code for the ATtiny13 and tested all the features to ensure they worked as intended. The button echo function performed so quickly that any slight delay, caused by reading the button state and then echoing it, was imperceptible.

Next, I measured the power consumption during power-down mode, and fine-tuned the CPU parameters to achieve the datasheet-specified power consumption. The final solution with the ATtiny13 consumed approximately 300nA, which is the lowest possible value according to the datasheet [2].

Afterward, I ported the code to the ATtiny10. During this process, I discovered that many of the configuration registers were incompatible with the ATtiny10, despite most other family variants being compatible. I rewrote the configuration and other special registers to match the ATtiny10’s requirements. I then re-optimized the power consumption in power-down mode, achieving approximately 100nA, the lowest possible value as specified in the ATtiny10 datasheet [1].

NEXT STEPS

All six required features outlined at the start were met. However, the power CPUs offer additional built-in features such as the ADC that could be utilized. Although the ATtiny10 is out of spare I/O pins, a spare pin could be freed up if the button echo feature is not required or if the ATtiny13 version is used.

This spare pin could be used to monitor the battery voltage and cut power to the system if the battery runs low. Implementing this feature would require only two external resistors to divide the voltage, which would then be connected to the spare I/O pin. The CPU uses its ADC to measure the battery voltage and take appropriate action if needed. To avoid unnecessary power consumption during power-down mode, the resistors should be placed after the pFET.

In my designs, I typically integrate voltage monitoring into the system CPU, allowing the battery level to be displayed on an LED or screen. However, this stand-alone approach may be beneficial for others who require simpler monitoring functionality.

CONCLUSION

I have described two implementations of the power solution, both of which consume so little power that their usage is negligible compared to the battery’s self-discharge rate. Both solutions share the same feature set, are compact, and cost around $1-$2. For completeness, a schematic of the power solution for the ATtiny4/5/9/10 with the ISP connector are shown in Figure 7, which is needed to program the device.

So far, I have tested the power solution on my evaluation board. I have also integrated it into the next version of my laser tag guns, which will undergo testing soon. This integration enhances user-friendliness by eliminating the risk of forgetting to turn the devices off. Additionally, charging is simplified—users only need to plug in a USB power cable ,and don’t need the unlogic step of turning on the power switch. 

REFERENCES
[1] ATtiny10 datasheet:  https://ww1.microchip.com/downloads/en/DeviceDoc/ATtiny4-5-9-10-Data-Sheet-DS40002060A.pdf
[2] ATtiny13 datasheet:  https://ww1.microchip.com/downloads/en/DeviceDoc/doc2535.pdf

RESOURCES
Microchip | www.microchip.com

Code and Supporting Files

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • APRIL 2025 #417 – Get a PDF of the issue

Sponsor this Article