Power Sequencing, Reset Order, and the First Power-On

A board that has never been powered is a collection of unverified assumptions. Each device expects its supplies in a particular order, its reset held until those supplies are valid, and its clock running before it releases the reset. The first power-on either confirms that the assumptions were consistent with each other or produces a board that draws current and does nothing, and the difference between the two outcomes is usually a sequencing detail that no schematic symbol makes visible.

Why supply order is a requirement and not a preference

A CMOS device’s absolute maximum ratings include a constraint that is easy to overlook: no input may be at a higher potential than the device’s own supply by more than a diode drop, and in some parts by more than a few hundred millivolts. The reason is the ESD protection structure at every pin, which is a diode from the pin to the supply rail and another from ground to the pin. If an input is driven while the device’s supply is at zero, the upper diode conducts and the input signal becomes a supply for the device, feeding current into a rail that the regulator has not yet brought up.

Two failure modes follow. The obvious one is excessive current: a driver sourcing into an unpowered device’s rail through a protection diode can exceed the diode’s rating, and the current path through the substrate can trigger a parasitic thyristor — the latch-up condition that JESD78 tests for. A latched device stays in a low-resistance state until power is removed, and if the current is not limited the device is destroyed.

The less obvious one is functional. A device powered through its inputs is in an undefined state: some internal nodes are at valid levels, others are not, and the reset circuit may release before the bandgap reference has settled. The result is a device that starts in an indeterminate mode, which may be benign on one board and fatal on the next.

The design rule that follows is that every device’s supply must be valid before any signal reaches its pins. In practice this means the rails rise in an order defined by the devices’ requirements, and the signals that cross between domains are gated until the last of the two domains is up.

Sequencing requirements in a real rail set

A typical board has several rails: a standby rail that is always present, a main logic rail, a memory rail, an I/O rail whose voltage depends on the interface standard, and one or more analog rails. The devices specify the order.

The common pattern for a processor is that its core supply rises before its I/O supply, or the reverse, depending on the part; the datasheet states which and gives a maximum time between the two. A memory device often requires its supply and its termination reference to be established before its inputs are valid. An analog-to-digital converter may require its analog rail before its digital rail to avoid forward-biasing internal junctions.

Three parameters describe a sequencer’s behaviour, and all three are specified rather than assumed. The first is the order, which is a partial order rather than a total one: several rails may rise together if no device constrains their relative timing. The second is the delay between successive rails, which must be long enough for each to reach regulation but short enough to satisfy the devices’ maximum separation. The third is the tolerance on each rail’s ramp — a rail that rises too slowly through a device’s threshold region can leave the device in an indeterminate state for longer than its internal reset can tolerate.

A rail that rises monotonically is the usual requirement, and it is a constraint on the regulator rather than the sequencer. A regulator with a large capacitive load and a current-limited startup can plateau, dip, or ring during ramp, and a device whose internal power-on reset releases at a fixed threshold may release twice. The monotonicity requirement is why some regulators specify a soft-start that controls the ramp rather than merely limiting the current.

The sequencer, the power-good chain, and the reset tree

The mechanism that enforces order is usually a chain. Each regulator has a power-good output that asserts when its output is within tolerance; the sequencer enables the next regulator only when the previous one’s power-good is asserted, and it waits a programmed delay before doing so.

The chain has two failure modes that are worth designing against. The first is a power-good signal that asserts early: a regulator’s power-good comparator has its own threshold and its own delay, and a part whose threshold is at 90% of nominal will declare success while the rail is still 10% low. Devices that need the rail within 5% will be released into an out-of-tolerance supply. The second is a power-good that never asserts, which stalls the chain and leaves the board with some rails up and no indication of which one failed — unless the sequencer’s status is readable, which is the reason sequencers with an I2C or SPI status register exist.

The reset tree is a separate structure that depends on the same information. A device’s reset must be held until its supply is valid, its clock is running, and any upstream device that drives its inputs has finished its own reset. The usual implementation is a supervisor with a programmable delay, or a reset controller that takes the power-good signals and the clock’s lock indicator as inputs and releases resets in the reverse of the power order.

The reverse order matters. Devices should come out of reset in the reverse of the order they were powered, so that a device driving another’s input is functional before the input becomes significant. A board where all resets are tied together releases every device at once, and for a brief window two devices may drive the same bus in opposite directions.

Bus contention during the window before reset

The interval between power-good and reset release is when contention happens. Every device on a shared bus is in its reset state, and the reset state of a bidirectional pin is not guaranteed to be high-impedance. Some devices drive their outputs low during reset; others enable weak pull-ups; others leave the pin floating.

When two devices drive a shared line in opposite directions, the current is limited only by the two output impedances and the trace resistance. At 3.3 V with two 30 Ω drivers, the contention current is over 50 mA, and the resulting node voltage sits at some intermediate level that neither device recognises as a valid logic level. The current flows continuously until one device releases the line, which for a device held in reset may be milliseconds.

The mitigations are structural. Series resistors on shared lines limit contention current at the cost of edge rate. Bus switches or multiplexers that are disabled until the system is out of reset eliminate it. Enabling the bus in a defined order — one device’s output driver enabled only after the other’s is known to be in a high-impedance state — is the software-visible version and requires the reset controller to release the devices in sequence.

The same window is when a device’s input can be driven by a signal from an unpowered neighbour. The protection-diode path described above is the mechanism, and the mitigation is a level translator or a bus switch with a powered-off high-impedance behaviour, sometimes specified as a partial-power-down capability in the part’s datasheet.

Boundary scan as the first diagnostic

Once the rails are up and the clocks are running, the question is whether the board is correctly assembled. The tool for that is the IEEE 1149.1 test access port, which most complex devices provide.

The mechanism is a shift register around the device’s periphery. Each I/O pin has a boundary-scan cell that can capture the pin’s value, or drive a value onto the pin, under control of a state machine clocked through the test access port. Chaining the devices’ ports together — one TDI to TDO connection per device, with a shared TCK and TMS — gives a single shift register spanning every device on the chain.

The tests that follow from that are the ones that find assembly faults. An interconnect test drives a pattern from one device’s output cell and captures it at the receiving device’s input cell; an open trace shows as a captured value that does not match, and a short between two traces shows as two nets carrying the same pattern. The test finds the same class of structural fault that an in-circuit fixture finds — an open trace, a solder bridge — without the fixture, and it is why boundary scan exists.

The limits are equally concrete. Boundary scan tests the connections between devices that are on the chain. It does not test a net that goes to a passive component, a connector, or a device without a port. It requires the chain to be intact: a single broken TCK or TMS connection makes every device beyond the break invisible, and the first diagnostic step on a dead chain is to check the four signals and the reference voltage at each device’s port. And it requires the devices to be powered and out of reset, with the test access port enabled by whatever pin strapping the device requires.

# Interconnect test, simplified: drive a walking-one pattern from the source
# cells and compare what the destination cells captured.
NETS = ["D0", "D1", "D2", "D3", "D4", "D5", "D6", "D7"]

def expected(pattern):
    return {n: (pattern >> i) & 1 for i, n in enumerate(NETS)}

def captured_with_faults(pattern, opens=(), shorts=()):
    got = expected(pattern)
    for n in opens:
        got[n] = 0            # no driver reaches the receiver
    for a, b in shorts:
        got[a] = got[b] = got[a] & got[b]   # wired-AND of the two nets
    return got

for p in (0x55, 0xAA):
    exp = expected(p)
    got = captured_with_faults(p, opens=("D5",), shorts=(("D1", "D2"),))
    bad = [n for n in NETS if got[n] != exp[n]]
    print(f"pattern {p:#04x}: mismatches {bad}")

The point of the walking pattern is that a short between two nets is only detectable when the pattern drives them to different values. A single all-ones or all-zeros pattern detects opens but not shorts, which is why the test applies several complementary patterns rather than one.

When the board still does nothing

The diagnostic order that follows from the mechanisms is bottom-up, and each step is a measurement rather than an inference.

Check the rails first, in sequence order, with a meter rather than a scope: a rail that is present but low by 10% explains a device that never releases reset. Check the sequencing with a scope on the enable and power-good signals if the rails are present but the order is wrong. Check the clocks next, because a device with no clock holds its internal reset; a clock that is present but at the wrong frequency, or that stops when a configuration pin floats, produces a board that appears dead.

Then check the reset tree: which device is holding which other device in reset, and whether the supervisor’s delay has expired. Then check the straps — the configuration pins that select boot source, port width, and test mode — because a floating strap is read as a valid level by some devices and as an undefined one by others, and the difference determines whether the device comes up in the mode the design expects.

Only after those are confirmed does the bus traffic make sense to examine. A board that fails at the first step and a board that fails at the last present the same symptom, and the measurements are what separate them. The probes used for those measurements carry their own limits, which is the subject of Probing High-Speed Nets Without Measuring the Probe, and the sequencing decisions made at bring-up are constrained by the same return-path and impedance rules that governed the layout: see Return Current Paths and Why Loop Area Sets Trace Inductance and Power Delivery Network Impedance and the Target It Must Hold.