The Repair LibraryRead · Learn · Master

Power Sequencing Failures

The chapter closes on the power fault that defeats everything taught so far, because it is invisible to the method that found all the others. Section 3.3 diagnosed a failed power system by asking of each rail whether it is present and at the right voltage — and that rail-by-rail check is powerful precisely because most power faults are a missing or wrong rail. But there is a class of fault where every single rail measures present and correct, at exactly its expected voltage, and the device is still completely dead — and no voltmeter, however carefully applied, will ever find it, because the fault is not in the presence of the rails but in the order and the timing of their arrival. Modern devices do not simply need their rails; they need them brought up in a defined sequencing order and within defined timing windows, because a processor that comes out of reset before its core rail is stable, or an I/O rail that rises before the rail it must follow, does not work no matter how perfect each voltage is once everything settles. The rails hand off to one another through power-good signals, and the processor is held in reset until the sequence completes, so a single rail that is late, a power-good that never asserts, or a reset released too early stalls or corrupts the whole bring-up while leaving every rail looking flawless a moment later on a meter. This section teaches the fault a static check cannot see and the only method that can: capturing the sequence in time. A sequencing failure is diagnosed not with a meter but with a multi-channel oscilloscope or logic analyzer triggered on power-on, watching all the rails and the key control signals — the enables, the power-goods, the reset — come up together, and reading their order and their timing against what a healthy bring-up should look like. The section — and the chapter — closes on the discipline that follows: when every rail is present and the device is still dead, stop measuring voltages and start capturing the sequence, because presence is not order, and a rail that is there is not the same as a rail that arrived on time.

ProfessionalMedium Risk23 min read

What You Will Learn

  • You will learn that a sequencing failure leaves every rail present and correct yet the device dead, invisible to a voltmeter.
  • You will learn why order and timing matter — a rail late or out of order, or a reset released too early, breaks a bring-up.
  • You will learn the role of power-good signals and reset in gating a sequence, and how their failure stalls it.
  • You will learn to capture the rails and control signals in time on a multi-channel scope and read the sequence.
  • You will learn to compare a captured sequence to a known-good bring-up and find the rail or signal that is late, missing, or out of order.

What You Will Be Able To Do

  • You will be able to recognize a sequencing failure — every rail present, device dead — and stop looking for a missing rail.
  • You will be able to explain why the sequencing order and rail timing matter, not just the final voltages.
  • You will be able to trace how power-good signals and reset gate a bring-up and how their failure stalls it.
  • You will be able to capture a board's power-on sequence in time on a multi-channel scope.
  • You will be able to read a captured sequence against a known-good one and locate the late, missing, or out-of-order event.

Required Tools

  • A multi-channel oscilloscope or logic analyzer — the only instrument that captures the rails and control signals in time
  • A known-good sequence capture of the same board — the healthy bring-up the fault is read against
  • Fine-tip probes and a power-on trigger — to catch the enables, power-goods, and reset as the board wakes
  • The notebook — this section records each rail's arrival order and timing, and where the sequence stalls

When NOT to Attempt This

Do not attempt this section if any of the following apply to you:

  • You are not experienced with the specific repair type described here.
  • You do not have professional-grade equipment for this procedure.
  • The device has sentimental or high monetary value and you cannot afford a mistake.
  • You have not successfully completed this repair on a sacrificial device first.

Section Overview

The chapter closes on the power fault the rail-by-rail check cannot see (pmic-failure-analysis). A sequencing failure leaves every rail present and at its correct voltage — and the device completely dead. No voltmeter finds it, because the fault is not in the presence of the rails but in the order and timing of their arrival (power-rail-sequencing). Modern devices need their rails brought up in a defined sequencing order and within defined rail timing windows. A processor out of reset before its core rail is stable, or an I/O rail rising before the rail it must follow, does not work however perfect each voltage settles (pmic-architecture-in-modern-devices). Rails hand off through power-good signals, and the processor is held in reset until the sequence completes. So a late rail, a power-good that never asserts, or reset sequencing that releases too early stalls the bring-up while every rail looks flawless a moment later. The fault is seen only in time. A multi-channel scope triggered on power-on captures the rails and the enables, power-goods, and reset, read against a known-good bring-up (diagnosing-with-the-oscilloscope). When every rail is present and the device is dead, stop measuring voltages and capture the sequence — presence is not order.

Why This Matters

This is the fault that humbles the voltmeter and closes the power chapter (pmic-failure-analysis). This matters because a sequencing failure is invisible to the method that finds every other power fault: the rail-by-rail check that Section 3.3 built passes every rail — each present, each correct — so a technician who trusts it declares the power good and is stuck, because the fault lives in time, where a static measurement cannot look (power-rail-sequencing). This matters because order and timing are real requirements, not niceties: a rail late to its window or out of its order can hold a processor in a bad state, release it onto unstable power, or violate a chip's power-on requirement, so a bring-up that is perfect at DC can still fail entirely (pmic-architecture-in-modern-devices). It matters because the diagnosis needs a different instrument and a different mindset: a meter reads one node at one moment, but a sequence is many nodes across time, so it takes a multi-channel capture triggered on power-on and read against a known-good bring-up to see the event that is wrong (diagnosing-with-the-oscilloscope). And it matters because it completes the technician's power ability: with theory, architecture, failure analysis, and now sequencing, a technician can diagnose a power system whether its fault is a missing rail, a shorted one, or a present-but-mistimed one — the last of which is the hardest and the one that separates a complete power repairer from a partial one. When the rails are all there and the device is still dead, the fault is in the sequence — and only a capture in time will show it.

Required Prerequisites

Before starting this section, you should have completed:

  • PMIC Failure Analysis — the rail-by-rail method that finds a missing or shorted rail; this section handles the fault that method cannot see, where every rail is present.
  • Power Rail Sequencing — the foundational concept of ordered, timed rail bring-up; here it becomes a fault to diagnose in a real device.
  • Fine-tip probe accessories and ground springs — a multi-channel capture needs clean, low-inductance connections to several rails and signals at once, and a poor ground turns a real sequence into noise.
  • Low-tack labels for the channels — each scope channel is tagged to its rail or signal — core, I/O, power-good, reset — because a sequence capture is unreadable if the traces are not named.
  • Printed known-good sequence captures — the healthy bring-up is kept at hand, because a captured sequence means something only against what right looks like.
  • A multi-channel oscilloscope or logic analyzer — the essential instrument, able to capture several rails and control signals together, triggered on power-on.
  • A donor board that powers on cleanly — to capture a healthy bring-up as the known-good reference before any faulty one is read.
  • A board with a sequencing fault — a late rail, a missing power-good, or a mistimed reset, so the captured-versus-known-good comparison is practiced on a real failure.

Real-World Applications

This is the section a technician reaches when the power looks perfect and the device still will not wake. A repairer whose board shows every rail present yet dead stops chasing a missing rail and captures the sequence, because all-rails-present-but-dead is the signature of a sequencing fault, not a regulator fault (pmic-failure-analysis). A technician capturing a stalled bring-up finds a power-good that never asserts, so the sequence waits forever for a handshake that does not come, and the rail behind that power-good is the fault (power-rail-sequencing). A bench chasing an intermittent no-boot captures the reset and the core rail together and sees reset releasing a hair before the rail is stable, a reset sequencing fault that a meter would never reveal (diagnosing-with-the-oscilloscope). And a tech comparing a faulty board's capture to a known-good one sees one rail arriving out of its order and knows exactly which enable or load switch is mistimed (pmic-architecture-in-modern-devices). The confusions this prevents: a mistimed bring-up hunted as a missing rail, a stalled sequence blamed on a good regulator, a reset-timing fault invisible to the meter, and a sequence read without the known-good it only means against.

Common Challenges

  • The rails all measure perfect. Every rail is present and correct, so the meter says the power is good — the fault is in time, and the static check that finds every other power fault is blind to this one (pmic-failure-analysis).
  • A sequence is many signals at once. One rail at one moment tells nothing about order — the fault appears only when several rails and their control signals are captured together across the bring-up (diagnosing-with-the-oscilloscope).
  • The capture means nothing alone. A single sequence looks plausible until compared — only a known-good bring-up shows which event is late, missing, or out of order (power-rail-sequencing).
  • The trigger and the ground are unforgiving. A capture triggered late or grounded poorly turns a real sequence into noise — the bring-up happens once per power-on and must be caught cleanly (pmic-architecture-in-modern-devices).

Safety Notes

Risk Level: Medium. This section captures live power-on sequences on powered boards and closes the power chapter, so the standing bench law, the always-on caution, and live-power care all apply.

  • Attach probes unpowered, capture powered — move probes and add channels with the board off, then reapply power to capture, so a probe slip does not short live rails.
  • Proper grounds, never bridge rails — each channel gets a clean low-inductance ground; a slip across two live rails can short them and damage the board.
  • Clear a suspected short first — a board that may carry a downstream short is cleared before it is power-cycled repeatedly to capture a sequence.

Professional Tips Before Starting

  • Suspect sequencing when all rails are present. Every rail good and the device dead is the signature — stop hunting a missing rail and capture the sequence (pmic-failure-analysis).
  • Capture, do not measure. A sequence lives in time across many signals — a multi-channel capture triggered on power-on is the only view of it (diagnosing-with-the-oscilloscope).
  • Always have a known-good. A lone capture looks plausible — only the healthy bring-up shows which event is wrong (power-rail-sequencing).
  • Include the handshakes. Rails alone do not tell the story — capture the power-goods and the reset, because the sequence is gated by them (pmic-architecture-in-modern-devices).
  • Ground clean and trigger right. The bring-up happens once per power-on — catch it with low-inductance grounds and a power-on trigger, or the capture is noise.

Reading a Broken Sequence

The Fault the Meter Cannot See

The chapter's final fault is defined by what it is not: it is not a missing rail, not a shorted rail, not a wrong voltage — it is a rail that is perfectly present and simply arrived at the wrong time (pmic-failure-analysis). This is why the rail-by-rail method that closed the last section is blind to it. That method asks of each rail whether it is present and at the right voltage, and against a sequencing fault the answer for every rail is yes — every rail is there, every voltage is correct, and the meter, moving node to node, finds nothing wrong. And yet the device is completely dead. A voltmeter reads one node at one moment, long after the bring-up is over and everything has settled, so it sees the steady state and never the sequence — and the fault existed only during the bring-up, in the order and timing of the rails as they rose, which is gone by the time a meter probes a settled board (power-rail-sequencing). This makes the recognition itself the first skill. When every rail measures present and correct and the device still will not start, that pattern — all rails good, device dead — is not a puzzle to be re-measured but a signature to be named: it is a sequencing fault, and no amount of further static measurement will reveal it. The technician who does not know this class of fault exists is trapped, re-measuring the same good rails and concluding, wrongly, that the power is fine and the fault must be elsewhere. All rails present, device dead, meter useless — the recognition that turns an impossible fault into a known one, and points at the only method that can see it.

Order, Timing, and the Handshakes That Gate Them

To find a sequencing fault you must know what a healthy sequence requires, because the fault is a violation of those requirements (power-rail-sequencing). A modern device does not power all its rails at once. It brings them up in a defined sequencing order — a required sequence, such as a core rail before the I/O rails that depend on it, or a set of rails before the processor is allowed to start — because bringing a rail up out of that order can forward-bias a chip's internal structures, cause excess current, or violate a device's stated power-on requirement. And each rail has a rail timing window. A rail must reach regulation within a certain time and hold its relationship to the others, because a rail that rises too slowly or too late misses the moment the sequence needed it, even if it eventually reaches the right voltage. The sequence is held together by handshakes. As each rail comes into regulation, its power-good signal asserts, and that signal gates the next step — enabling the next rail, or telling the sequencer the stage is complete — so the bring-up is a chain of rails each waiting on the power-good of the one before (pmic-architecture-in-modern-devices). And the processor is held out of action until the end. Reset sequencing keeps the processor in reset until all its rails are up and stable, then releases it — so reset is the last handshake, and its timing is critical: released too early, the processor starts executing on power that has not settled and hangs or corrupts; never released, the processor never starts at all. Order, timing, power-goods, reset — the four things a healthy sequence gets right, and therefore the four things a sequencing fault gets wrong.

Capturing and Reading the Sequence

Because the fault lives in time, the only way to see it is to capture the bring-up in time and read it against what right looks like (diagnosing-with-the-oscilloscope). The instrument is a multi-channel one. A multi-channel oscilloscope or a logic analyzer can watch several rails and control signals at once, and triggered on the power-on event it captures them all together as the board wakes — the one view in which order and timing are visible. The channels must be chosen to tell the story. The key rails, the power-good signals, and the reset are probed together, each channel labeled, so the capture shows not just the rails rising but the handshakes that gate them and the reset that ends the sequence (pmic-architecture-in-modern-devices). Then the capture is read against a known-good. A healthy board of the same model is captured the same way, and the two are compared — because a single sequence looks plausible on its own, and only the difference from a known-good bring-up reveals the event that is wrong: the rail that rises later than its twin, the power-good that asserts on the good board and never on the bad, the reset that releases before its rail on the faulty capture and after it on the healthy one. That difference is the fault. A rail late to its window points at its regulator or its enable; a power-good that never asserts points at the rail behind it or the monitor that watches it; a reset released too early points at the reset logic or the power-good it should have waited for (pmic-failure-analysis) — each a specific fault the capture has localized that no meter could. Capture in time, include the handshakes, compare to known-good, and read the difference — the method that makes the invisible sequencing fault a located one, and the note the power chapter ends on.

Common Mistakes

  • Declaring the power good because the rails are present. Every rail measures correct, so the power system is cleared — a sequencing fault leaves all rails present, and the power is not good until the sequence is (pmic-failure-analysis).
  • Trying to find a sequence with a meter. The rails are re-measured node by node — a meter reads one node at one settled moment and cannot see order or timing; only a capture in time can (diagnosing-with-the-oscilloscope).
  • Capturing without the handshakes. Only the rails are probed — the power-goods and reset gate the sequence, and without them the capture shows rails rising but not why the bring-up stalls (pmic-architecture-in-modern-devices).
  • Reading a capture with no known-good. A lone sequence is judged by eye — it looks plausible until compared, and only a known-good bring-up reveals which event is late, missing, or out of order (power-rail-sequencing).
  • Blaming a rail for a timing fault. A late rail's regulator is replaced — the rail may be late because its enable or a preceding power-good is late, so the capture must trace the timing to its true origin.

Troubleshooting Guidance

  • Every rail is present and correct but the device is dead — suspect sequencing and capture in time: this pattern is the signature of a sequencing fault, invisible to a meter, so stop re-measuring rails and capture the bring-up on a multi-channel scope (pmic-failure-analysis).
  • A captured bring-up stalls partway — find the handshake that never comes: a power-good that fails to assert stalls the sequence waiting for it, so identify the missing power-good and the rail or monitor behind it (power-rail-sequencing).
  • An intermittent no-boot on a board with good rails — capture reset against its rail: a reset released a little before its rail is stable causes an intermittent hang, a timing fault seen only by capturing reset and the rail together (diagnosing-with-the-oscilloscope).
  • A capture looks plausible but the board is dead — compare to a known-good: read the faulty capture against a healthy one of the same board, because the fault is the event that differs — a rail out of order, a late power-good, an early reset (pmic-architecture-in-modern-devices).

Verification & Testing Methods

Confirm your sequencing-diagnosis skill before completing the chapter:

  • [ ] I can recognize a sequencing failure — every rail present, device dead — and stop looking for a missing rail.
  • [ ] I can explain why the sequencing order and rail timing matter, not just the final voltages.
  • [ ] I can trace how power-good signals and reset sequencing gate a bring-up and how their failure stalls it.
  • [ ] I can capture a board's power-on sequence in time on a multi-channel oscilloscope, including the handshakes.
  • [ ] I can read a captured sequence against a known-good one and locate the late, missing, or out-of-order event.

Then try the practice exercises below — sequence capture and comparison only, under the callout's live-capture and grounding discipline.

Practice Exercises

  1. Recognize the signature (6 minutes, desk reasoning from a described board). For a board where every rail measures present and correct yet the device is dead, write why this pattern is a sequencing fault and why no further static measurement will find it, so the recognition is fixed before any capture (pmic-failure-analysis).
  2. Capture a known-good bring-up (7 minutes, healthy donor board, multi-channel scope). On a board that powers on cleanly, probe the key rails, a power-good, and reset, trigger on power-on, and capture the healthy sequence, labeling each channel — building the reference every fault is read against (diagnosing-with-the-oscilloscope).
  3. Read the handshakes (7 minutes, same capture). From the known-good capture, trace how each rail's power-good gates the next step and how reset releases only after the rails are up, annotating the order and timing, so the sequence is understood as a gated chain, not just rising lines (power-rail-sequencing).
  4. Locate a fault by comparison (5 minutes, faulty board versus the known-good). Capture a board with a sequencing fault the same way and compare it to the known-good, identifying the event that differs — a late rail, a missing power-good, an early reset — and naming the fault it points to (pmic-architecture-in-modern-devices).

These core steps — the recognized signature, the known-good capture, the read handshakes, and the fault located by comparison — are tested in the Chapter Quiz at the end of this chapter, where a score of 80% is required to continue.

Key Takeaways

  • A sequencing failure leaves every rail present and at its correct voltage while the device stays dead, because the fault is in the order and timing of the rails' arrival, not their presence — so it is invisible to the rail-by-rail check and to any meter (pmic-failure-analysis).
  • Rails must come up in a defined sequencing order and within rail timing windows, because a rail out of order or late to its window breaks a bring-up however correct each voltage settles (power-rail-sequencing).
  • The sequence is gated by handshakes — each rail's power-good enables the next step, and reset sequencing holds the processor in reset until the rails are stable — so a late rail, an unasserted power-good, or an early reset stalls or corrupts the whole bring-up (pmic-architecture-in-modern-devices).
  • The fault is seen only in time — a multi-channel oscilloscope triggered on power-on captures the rails and the enables, power-goods, and reset together, the one view in which order and timing are visible (diagnosing-with-the-oscilloscope).
  • A capture means something only against a known-good bring-up — the difference between them is the fault: the rail that is late, the power-good that never asserts, or the reset that releases too early, each pointing at a specific cause a meter could never find.

Skills Learned

After completing this section, you can:

  • Recognize a sequencing failure — every rail present, device dead — and stop looking for a missing rail.
  • Explain why the sequencing order and rail timing matter, not just the final voltages.
  • Trace how power-good signals and reset gate a bring-up and how their failure stalls it.
  • Capture a board's power-on sequence in time on a multi-channel oscilloscope.
  • Read a captured sequence against a known-good one and locate the late, missing, or out-of-order event.

Glossary Additions

New terms introduced in this section:

  • sequencing order — the defined order in which a device's power rails must come up — and, on shutdown, come down — enforced by the PMIC or a sequencer, such as a processor core rail before the I/O rails that depend on it, or a specified set of rails before the processor is allowed to start. The order is a real requirement, not a convenience: bringing a rail up out of its sequence can forward-bias a chip's internal structures, draw excess current, or violate a device's stated power-on requirement, so the device fails to start even though every rail eventually reaches its correct voltage. Its significance in repair is that a violated sequencing order is invisible to a static rail check — every rail is present and correct once things settle — and can be seen only by capturing the bring-up in time and comparing the order of arrival to a known-good sequence.
  • rail timing — the timing relationships a power sequence must meet: each rail reaching regulation within a required window and holding its correct timing relative to the other rails and to the control signals that gate the sequence. Timing matters as much as order, because a rail that eventually reaches the right voltage but rises too slowly or arrives too late has still missed the moment the sequence needed it, and the bring-up fails. Like a violated order, a rail-timing fault leaves every rail measuring present and correct on a settled board, so it is found only by capturing the sequence in time on a multi-channel instrument and reading each rail's arrival and slope against a known-good bring-up, where a rail that is late or slow stands out against its healthy twin.
  • reset sequencing — the timing of the processor's reset release relative to its power rails: the processor is held in reset while its rails come up and stabilize, and reset is released only once the sequence is complete, so that the processor begins executing on stable, valid power. It is the last and one of the most critical handshakes in a bring-up, because its timing must be exactly right — reset released too early starts the processor on power that has not yet settled, causing a hang or corruption that often presents as an intermittent no-boot, while reset never released leaves the processor inert though every rail is present. A reset-sequencing fault is a classic sequencing failure invisible to a meter, found by capturing the reset signal together with its rails and reading whether reset releases before or after the rails are stable against a known-good capture.

Suggested Next Sections

Must read next:

Recommended: