# Low power switch input with MCU wake-from-sleep interrupt?

Im trying to read the falling edge of digital logic input to wake up a microcontroller. Below is the circuit I have used. There is an RC filter to provide a ~5ms debounce time, and a 100K pullup so the circuit doesn't use lots of power while the switch is in its on-state. The switch may be in its on-state for roughly 10% of the circuit operation time.

simulate this circuit – Schematic created using CircuitLab

The problem with my circuit may seem obvious to some but I seem to have overlooked it; The input is pulled low quickly (discharges) just how i wanted it, but it is pulled high (charges) very very slowly due to the 100K pullup.

I don't want the circuit to take a long time to charge up (ideally <20ms) but I also don't want it to draw lots of current when the switch is in its on-state. Are there any engineering tricks i can employ to achieve these two things together? I assume its a classic problem but I cannot find any solutions.

• Use a smaller C1? Aug 21 '18 at 5:26
• Given the information i supplied in my original post, that is a completely legitimate answer. However, i'm concerned about the potential for the cap to properly provide decoupling attributes if i pick a cap size that is too low for a big noisy switch. This may not actually be of concern, but i want to entertain the hypothetical that it is.
– Joe
Aug 21 '18 at 22:54
• Then use a larger R2? Aug 22 '18 at 0:56
• I'm not sure what that would achieve besides increasing the time of charging and discharging the input.
– Joe
Aug 22 '18 at 13:25
• well it would cancel out reducing the capacitance which would decrease the time of charging and discharging the input? Aug 22 '18 at 22:45

Why are you using falling edge for interrupt at all? However small, you still have some current permanently flowing through the pull-up, which defeats the purpose of sleep mode. Plus the pull-up makes you RC filter lopsided.

Anyway, you have several options. First, you can use SPDT switch which will guarantee same timing for charge and discharge. See first schematics below (BTW, it works for either edge).

If you want to keep using rising edge and SPST switch you can

• use two identical resistors, but shunt one of them with diode, resulting in almost the same rising and falling times (tweak one of the resistors to counter voltage drop on a diode, if you wish), and
• recalculate your RC for high resistance and much smaller capacitance, to keep quiescent current low for the same time constant, e.g. 50k resistors and 0.1 µF capacitor.

• Thanks for your answer. The switch is actually external to the device and required to be a momentary-style switch. I'd love to use an SPDT if that was an option. The switch is the only external part, however, so the switch can be configured as high-side. I'm interested to know why you believe there'll be any more current draw in the low-side configuration than the high-side? Are you referring to the leakage current of the MCU I/O pins?
– Joe
Aug 26 '18 at 10:29
• Yes, I am referring to I/O input leakage. For example ATmega328 has input current 1uA, which is 10 times more than power-down sleep mode at 0.1uA. And yes, you can use SPDT switch in first schematics for either rising or falling edge. The only difference would be in that additional leakage current. But if you re-balance RC for large resistance/small capacitance then it won't be much. The reason I mentioned it at all is that usually when people use sleep modes they go "all in", trying to save every nA. Aug 26 '18 at 15:47

You could, for example, insert a resistor in parallel with R1 only during the charging process. This would reduce the charging time. See my simple idea sketched in the figure below. In normal operation, when the switch is open, the P-channel MOSFET is cut off. When the switch is closed and the voltage in the capacitor reaches a low value, the voltage $Vgs$ will be negative and if it becomes smaller than $Vgs_{TH}$ , it will cause the mosfet to conduct and insert the additional resistor in parallel with R1. I leave you with the proper dimensioning of the parts and the addition any other.

EDIT:

After you answered: "...It could indeed be a high side switch...", I suggest the modification below considering the low power application and the processor must wake up in occurrence of interrupts. The advantages:

1. The upper resistor will not consume power when the switch is open (so, can use a lower value as 10k for example).
2. Using a Schottky diode (with a lower forward voltage) will bring a higher voltage to the MCU interrupt pin - a good thing when the battery drains or the supply voltage is 3V, for example.

Warning: The resistive divider should be calculated taking into consideration the hysteresys levels of the GPIO pin for the specific MCU (to avoid false interruptions or to lose one). Also, disable the internal pull-up resistor.

• Thanks for your answer. That's a clever way if handling it, though I would want to steer clear of using FETs if I can due to reasons of cost. Clever method nonetheless.
– Joe
Aug 22 '18 at 13:21
• Do you need the configuration around switch be exactly this? Could it be high side, for example? NOTE: I 've changed the position of inserted resistor in order to ensure saturation. Aug 22 '18 at 13:34
• It could indeed be a high side switch
– Joe
Aug 26 '18 at 10:26

There is an RC filter to provide a ~5ms debounce time

Get rid of it. The MCU can debounce in software.

This allow you to lower C1 to something like 100nF, yielding a much shorter charging time.

Another optimization could be the internal Pullup/pulldown resistors inside the MCU - which can be turned off an back on after some time. While this would delay a "button up" event (because you can only detect it when pullup is on), there would be no current flow in pullup OFF (pulldown on) state.

• Thanks for your answer. The problem I have is coupling a solution with the fact that I am using the high-to-low event to trigger an interrupt and wake up the MCU. I don't want to use software denouncing as it is messy with interrupts, and I don't want to have to make the controller mess around with managing pull ups when it should be sleeping.
– Joe
Aug 21 '18 at 12:36