# Simple power on delay for 3.4v-5v serial device being powered by 5volt VCC

What I am trying to do

I am trying to build the most simple as possible circuit to give a 3.4v-5v serial device a 1-2 second power on delay from the embedded Linux device running at 5v that it is connected to directly to an onboard serial bus.

I have found lots of examples of power-on delay circuits, some with transistors, some with MOSFETs, some with just a capacitor and resistor. I'm not sure what I need to use.

WHY?

The serial device sends out a message as soon as it has power, the embedded Linux device aborts its boot sequence if it gets a serial message within the first second of power.

What I think would work, but I am not sure, so I would like help

From what I have read, I should be able to create the power on delay with a 100mf capacitor and a 33K 1% resistor. The capacitor will take about 2000ms to reach the power on voltage (3.4v) with the 33K resistor.

I have a basic understanding of how capacitors work. But, the part I lack the proper knowledge of is, once the capacitor hits 3.4volts, does it stay there? Or does each discharge cycle from the capacitor take 2000ms? If the latter, could someone point me in the right director for a circuit design that would provide steady power at 3.4-5v with a 2 second power on delay from a 5volt power source?

Thank You!

• What is the "serial device".
– RoyC
Dec 9, 2020 at 22:09
• got Got GOT to know more about the serial device. While your approach works on paper, it leaves the 33K resistor in series with the device's power input, something the device might not like. At a minimum, decrease the resistor to 1K and increase the cap to 2200 uF. Dec 9, 2020 at 22:34
• does the serial device have a reset signal that you could hold active for a second or two at powerup? Dec 10, 2020 at 5:44
• @jsotola, unfortunately not :( Dec 16, 2020 at 0:18
• then insert a gate between the serial device and the linux device ... use a delay circuit to disable the gate at powerup Dec 16, 2020 at 0:22

There are several issues here in addition to the one you are thinking about.

There are two problems with an RC network: first, you need a small resistor to survive the variation in load current while running, which means you need a truly huge capacitor. Also, very slow rise in voltage may not reliably trigger power-on-reset behavior. So really you need your RC circuit, 555 timer or whatever to control a silicon power switch.

If you're going to use a silicon power switch, you might as well let the host Linux system control it with a GPIO that has to be explicitly enabled and driven by post-boot software. In fact this is practically critical, because you need to de-power that serial device any time the Linux system does a warm reboot and not just a power cycle, otherwise, that's going to fail, too. Imagine an unprecedented bug, a watchdog reset... and an eternal lockup - could anything be more opposite to the design intent of those mechanisms?

There are two common solutions for silicon power switching: one is to use a purpose made part, for example a USB downstream port switch chip, like the 5-pin version of the RT9742. These burn just enough in "off" mode to be questionable in a battery powered design, but otherwise give you a lot of application simplicity - there are others which are probably better. The other is to use a small logic-level PFET, but then you need an NFET to drive that with a 3v3 signal...

Once you're switching power to your device, great, right? Well, actually, No! It turns out that most devices prohibit having an I/O voltage outside the supply voltage, so if the chip is powered off, you have to make sure any UART line going to it is low, too. A few parts have exceptions to this rule in the data sheet, but unless you know you are facing one, you need to honor it - not doing so can cause damage, and it can also cause a failure to reset when "real" power is applied. There are various solutions, involving software pin settings, logic gates, or possible a MOSFET level shifter which can tolerate having its low voltage side (but not its high voltage one) unpowered. Of course maybe you never transmit to the device but only receive from it; if so the issue is more with pull-up resistors. And yes, even a pull-up resistor can inject enough current into a powered off device to cause startup problems.

the embedded Linux device aborts its boot sequence if it gets a serial message within the first second of power

Danger! Even if you fix what you think can cause this, what about what you haven't? That sounds like a common behavior of U-Boot, and the risk here is that if boot is permanently interrupted by a serial character, some sort of glitch could make your device fail to start. You probably want to think about making U-Boot command mode time out and eventually reboot - a bit of a writeup I did over on Stackoverflow after seeing an actual failure of this sort lead to spending an afternoon figuring out how to enable it.

• great information to have. Unfortunately the device doesn't have any GPIOs on the pad that I can use. But your warning on accidently sending data to uboot via this method does seem like something I completely overlooked. I think I'm over solving the issue I'm having here (that being the device has a Bluetooth serial abstraction but not Serial, and I've failed to find a way to install it, and I don't have access to the kernel source to compile it myself. I'm going to just build a simple BT serial converter for the device and use that instead. Dec 16, 2020 at 0:22

A good solution is to use a proper supervisor circuit that will provide a bulletproof reset pulse regardless of startup conditions. During the 1second delay, nRESET (usually it's active-low) will be asserted.

For example, the MIC803 series from Microchip is available with a 1.12s minimum delay time and suitable voltage settings for 5V and other supply rails such as 3.3V.

You could use such a circuit (in conjunction with a high-side switch) to control the power to the device, but it's usually better to allow the power to come up but hold the device in reset for the duration.

• Blast, I am getting really out of date it is probably cheaper than a capacitor as well. +1
– RoyC
Dec 9, 2020 at 22:26
• @RoyC 16 cents in one-off at digikey.com, believe or it not. For some reason it's more expensive in 3K reels. Dec 9, 2020 at 22:28
• You could also add an AND gate like this to override the RST on warm reset Dec 10, 2020 at 6:24

Failing any of those, something like this might work:

simulate this circuit – Schematic created using CircuitLab

Open it and simulate it. Should get results like this:

An alternative could be something like this, but it might be a lot more finnicky. The SCR used is not ideal for this purpose and the model may be only so-so quality, so definitely experiment for best results:

A common method of achieving this would be to use a R-C network on the reset pin of the serial device. On power up this will hold the device in reset until the capacitor charges up (or discharges depending on reset polarity). The exact values of R and C can not be determined without knowing the specification of the reset threshold but will be in the range of 20K 100uF.