PCB Bring-Up & Debug interview questions

10 questions, easiest first

1. 1You've just received a freshly assembled prototype board. Before you plug in a debugger, apply clock signals, or try to talk to it over any communication bus, what do you check first and in what order? Walk me through the sequence you'd follow to bring this board up for the very first time, and explain what could go wrong if you skipped a step.intro

   Answer this one, graded

   Or just show what a strong answer covers

   I'd start with power, not signals. First I'd set the bench supply's current limit conservatively based on the expected draw, then bring the board up rail by rail, checking each with a multimeter and scope for correct magnitude, ripple, and sequencing before enabling anything downstream. Only once every rail is confirmed stable would I check that oscillators are running and PLLs have locked, since clock circuits need clean power to behave predictably. After that I'd confirm reset releases cleanly. Only then would I attempt any communication bus like SPI or debug/JTAG. The reason for this order is dependency: communication depends on clocks, clocks depend on stable power, and if you skip ahead you can misdiagnose a power problem as a communication problem, or worse, drive signals into a device that isn't properly powered and damage it.

   • Power rails checked first — States that all rails must be verified for correct voltage before anything else is touched, ideally with current limit set low on the bench supply.
   • Explains sequencing dependency — Explains that clocks depend on stable power and communication depends on clocks/reset, so checking out of order gives misleading results.
   • Names risk of skipping order — Gives a concrete failure mode, e.g. driving I/O before power is stable can damage the part or latch it up.
   • Mentions incremental verification — Describes checking each stage (rail, then oscillator/PLL lock, then reset release, then bus activity) before proceeding to the next.

   Where answers go wrong: Jumping straight to firmware or trying to talk over the debug interface without checking any rail voltages first. · Assuming the board is fine because an LED lit up, without measuring rail voltage or ripple. · Not setting a conservative current limit on the bench supply before first power-up.

2. 2You're building the bring-up checklist for a new prototype board that has a power stage, an MCU with an external crystal, and a UART bootloader. A teammate suggests skipping straight to flashing firmware over UART right after connecting power, reasoning that 'if it boots and talks over UART, everything downstream must be fine.' What's wrong with that plan, and what order would you actually use and why?intro

   This is about establishing a defensible bring-up order on a board you've never powered before, not about the specific firmware.

   Answer this one, graded

   Or just show what a strong answer covers

   I'd push back on skipping straight to firmware. A board booting and answering a few UART bytes doesn't prove the rails are actually healthy -- a marginal rail with excess ripple or a partial short can still let one transaction go through before things get flaky. The right order is: verify rails first, no shorts, correct magnitude, acceptable ripple, and correct sequencing if there are multiple rails. Then check that the clock actually starts and reset releases cleanly, since the MCU can't do anything meaningful otherwise. Only after that do I try communication, and only after communication is solid do I move to full functional test. The reason for that order is that each stage rules out a whole category of causes for the next one -- if I find a comms problem, I already know it's not a rail or clock issue, so I've narrowed the search a lot. Skipping ahead means if something goes wrong later, I have to re-verify all the earlier stages anyway, and I risk stressing a marginal rail further by loading it with active communication and firmware execution.

   • States rails must be verified before anything else — Answer explicitly says power rails (magnitude, no short, no excessive current draw) must be confirmed before enabling clocks or communication.
   • Explains why 'it boots once' isn't proof of health — Answer articulates that a marginal rail can still allow a single successful UART exchange while being unstable under load or over time, so success doesn't validate the rail.
   • Gives the correct staged order — Answer lays out rails -> clock/reset -> communication -> functional test as the sequence, or an equivalent staged approach.
   • Identifies a concrete risk of skipping ahead — Answer names a specific consequence such as stressing a shorted rail further, drawing conclusions from an unstable oscillator, or wasting time debugging firmware for a hardware fault.

   Where answers go wrong: Treating a successful UART handshake as proof the whole power/clock chain is healthy. · Jumping to firmware debug when the actual fault is a marginal or unverified rail. · Not distinguishing between 'board appears to work' and 'board is verified to work.'

3. 3You power up a new board on a bench supply with the current limit set. The instant you enable the output, the supply immediately hits its current limit and the rail voltage collapses toward zero. Walk me through exactly how you would localize the short, step by step, using tools you'd have on a normal bench.easy

   Answer this one, graded

   Or just show what a strong answer covers

   First I'd stop applying full power — I'd drop the current limit way down, or switch to a low-voltage bench supply, so I can probe safely without cooking whatever's shorted. With the board unpowered and any bulk caps discharged, I'd use an ohmmeter to check resistance from the rail to ground at a few points to confirm it really is near-zero ohms. Then I'd try to bisect the board: disconnect major subsystems, connectors, or lift a few suspect components to see if the short disappears, narrowing down which section it's in. Once I have a general area, I'd re-apply a small current-limited voltage and either use a thermal camera or my finger to find the component that's warming up, or inject a known small current and probe the copper with a scope/DMM to find where the voltage drops the most — that voltage gradient points straight at the short's location on the plane.

   • Keeps current limit low first — States they would reduce the current limit or use a low test voltage before further probing to avoid damaging or masking the fault.
   • Power-off resistance check — Describes measuring resistance from rail to ground with the board unpowered as an early diagnostic step.
   • Isolation/bisection strategy — Describes disconnecting or removing subsystems, connectors, or components in sections to narrow down which region contains the short.
   • Physical localization technique — Names a concrete localization method such as thermal camera, touch test, or injecting current and measuring voltage gradient across the copper to find the exact short.

   Where answers go wrong: Leaving the current limit high and repeatedly powering the board, risking further damage. · Relying only on visual inspection without measuring resistance or temperature. · Trying to test the whole board at once instead of isolating sections.

4. 4You probe a 3.3V rail directly at the load decoupling capacitor with your scope in AC-coupled mode and measure 150mVpp of ripple at the switching regulator's frequency. This rail feeds a precision ADC whose datasheet requires ripple to stay below 1% of the nominal voltage. What percentage ripple are you actually seeing, and is this rail acceptable to use as-is for that ADC?easy

   Answer this one, graded

   Or just show what a strong answer covers

   150mV divided by 3300mV is about 4.5%, which is well above the 1% the ADC datasheet requires — so this rail as measured is not acceptable to feed directly into that converter. That much ripple at the regulator's switching frequency will show up as noise in the ADC's conversions, effectively eating into its resolution, especially if it's anywhere near the sampling rate or its harmonics. Next steps would be adding more local bulk and high-frequency decoupling right at the ADC's supply pin, considering an LC filter to attenuate the switching frequency, or using a low-noise linear regulator downstream of the switcher just for the ADC's analog supply.

   • Correct percentage calculation — Computes 150mV / 3300mV as roughly 4.5%, showing the division and unit conversion.
   • Compares against spec correctly — States that 4.5% is well above the 1% requirement, so the rail fails spec for this load.
   • Proposes a next step — Suggests a remedy such as adding a local LC filter, additional bulk/decoupling capacitance, or a linear post-regulator to clean up the switcher's ripple.

   Where answers go wrong: Comparing 150mV directly to some absolute threshold without normalizing to the 3.3V rail. · Forgetting to convert mV to V or making an arithmetic slip in the percentage. · Concluding the rail is fine without proposing any mitigation despite it failing spec.

5. 5A board has a 1.0V core rail and a 3.3V I/O rail. The datasheet requires the core rail to reach 90% of nominal before the I/O rail turns on, with the two enables no more than 5ms apart. You scope both rails on power-up, triggered on the same event, and see the I/O rail cross its threshold 2ms before the core rail even reaches 0.5V. The board intermittently fails to enumerate on USB. How do you confirm sequencing is actually the cause, and what could happen inside the chip if this violation persists?easy

   Assume you have a two-channel scope and the board's power sequencer is configurable via resistor straps or firmware.

   Answer this one, graded

   Or just show what a strong answer covers

   First I'd put both rails on the scope with a common trigger, probably the core enable signal, so a single capture shows their relative timing rather than trusting two separate single-channel measurements. That gives me the actual delta and lets me check it against the datasheet's 90%-threshold, 5ms window directly -- here it's clearly violated since I/O turns on while core is still near zero. Internally, most chips have ESD clamp or substrate diodes between I/O pins and the core rail; if I/O is powered while core is floating low, current can flow backward through those structures, which can cause latch-up, excess leakage, or in the worst case cumulative damage over repeated power cycles. It would explain an intermittent enumeration failure because the exact rise-time relationship between the rails probably varies boot to boot depending on load and temperature, so sometimes it's benign and sometimes it corrupts the internal reset or leaves logic in a bad state. To fix it I'd either reconfigure the sequencer's enable delay, add an RC delay on the I/O enable pin, or adjust the supervisor thresholds so core is guaranteed to lead.

   • Proposes a correlated two-channel capture — Answer specifies scoping both rails simultaneously with a common trigger (e.g., on the enable signal or one rail's edge) to measure the actual time delta, not sequential single-channel measurements.
   • Compares measured delta to the datasheet window — Answer explicitly states the measured order/timing must be checked against the specified 90%-threshold and 5ms window to confirm a violation.
   • Names a physical failure mechanism — Answer describes current flowing through unpowered-die protection diodes or parasitic substrate paths when I/O is powered before core, potentially causing latch-up, excess leakage, or cumulative damage.
   • Ties the mechanism to the observed symptom — Answer connects the sequencing violation to intermittent USB enumeration failure, e.g., via unreliable internal reset or partial corruption of core logic at boot.
   • Proposes a concrete fix — Answer suggests reconfiguring the sequencer, adding an RC delay on the I/O enable, or adjusting supervisor thresholds to restore correct ordering.

   Where answers go wrong: Measuring the two rails on separate scope shots without a common trigger, losing the actual relative timing. · Assuming 'both rails eventually reach nominal' is sufficient without checking the specified ordering window. · Not connecting the sequencing violation to a physical damage/leakage mechanism, treating it as a purely digital timing issue.

6. 6A board's microcontroller isn't responding on its debug interface at all. You've confirmed the 3.3V rail is present, clean, and within spec. You then probe the crystal oscillator pins with your scope and see no oscillation whatsoever. What are the possible causes, and how would you narrow them down before concluding the crystal or the MCU is dead?medium

   Answer this one, graded

   Or just show what a strong answer covers

   First I'd question the measurement itself — a standard passive probe's capacitance can be enough to load down and stop a marginal crystal oscillator from starting, so I'd try a lower-capacitance probe, a 1x setting, or better, check a buffered clock output pin if the part has one, before trusting a 'no oscillation' reading. Next I'd verify reset is actually released and any oscillator-enable or configuration pins are correctly biased, since the amplifier simply won't run if the chip is held in reset. Then I'd inspect the crystal footprint for solder defects and confirm the load capacitor values match what the crystal's datasheet specifies for its load capacitance — wrong caps can prevent stable startup even with a good crystal. Only after ruling out the probe, reset state, and load caps would I consider swapping the crystal itself, and only after that would I suspect the oscillator amplifier inside the MCU is dead.

   • Identifies probe loading as a suspect — Notes that scope probe capacitance itself can suppress a marginal crystal oscillator, and proposes a lower-capacitance probing method or a buffered clock output instead.
   • Checks load capacitor values/footprint — Considers whether the load capacitors match the crystal's specified load capacitance or whether there's a soldering defect (open/bridge) at the crystal footprint.
   • Checks reset/enable state — Verifies reset is released and any oscillator enable/config pins are in the correct state before blaming the crystal or MCU.
   • Structured elimination, not component swap first — Describes a logical order of checks rather than immediately desoldering and replacing the crystal or MCU.

   Where answers go wrong: Assuming the crystal is bad and replacing it without first ruling out probe loading or reset state. · Not considering that the scope probe itself can prevent a marginal oscillator from starting. · Jumping to replacing the MCU without checking simpler, reversible causes first.

7. 7You've localized a shorted power rail to a general area of the board containing three different ICs, but you don't have time or spare parts to reflow all three off to test them individually. Describe how you would use trace cuts or pin lifts to bisect the fault and identify exactly which IC is at fault, while keeping the process as reversible as possible.medium

   Answer this one, graded

   Or just show what a strong answer covers

   I'd isolate one IC at a time rather than touching all three. Starting with whichever IC is easiest to access or seems most likely based on the failure symptoms, I'd either lift its power pin off the pad with a hot iron and tweezers, or make a small, precise cut in the trace right next to that pin — small enough that I could bridge it back later with a short jumper wire or solder blob. After isolating that one IC, I'd power the board at low current limit and measure resistance from the rail to ground again; if the short is gone, that IC is the culprit and I can stop there. If the short is still present, I'd re-bridge that pin, move to the next IC, and repeat. This keeps every step reversible and lets me narrow down the fault with minimal permanent changes to the board.

   • Describes isolating one IC at a time — Explains lifting a single pin or cutting a small trace segment feeding just one IC's power pin, rather than disturbing all three at once.
   • Reversible technique specified — Chooses a method (e.g., small trace cut re-bridgeable with a jumper wire, or a pin lift that can be re-soldered) that doesn't permanently damage the board.
   • Measures before and after each isolation — States they'd check rail-to-ground resistance with a meter after each isolation step to see if the short is gone.
   • Logical prioritization of order — Gives a reason for testing one IC before another, such as accessibility, likelihood, or cost of being wrong.

   Where answers go wrong: Cutting a large section of trace or fully desoldering all three ICs at once instead of isolating one at a time. · Not measuring resistance before and after each isolation step to confirm progress. · No plan to restore the board afterward, making the fix effectively destructive.

8. 8You've powered a new board and confirmed every rail is within spec. But when you probe the crystal oscillator pins on the MCU with your standard 10x scope probe, you see no oscillation at all -- just a flat DC level. Walk me through how you'd isolate the cause among the probe itself, the crystal, the load capacitors, and the MCU's internal oscillator driver.medium

   Assume a standard external crystal circuit with two load capacitors, and a bench scope with only a passive 10x probe available initially.

   Answer this one, graded

   Or just show what a strong answer covers

   First thing I'd question is my own measurement -- a standard 10x passive probe still has several picofarads of capacitance, which can be enough to detune or kill a marginal crystal oscillator loop, especially at low drive levels. So I'd either try a low-capacitance/active probe, or just measure very lightly and briefly, or use an alternate method like checking current draw signature instead of direct probing. If it's still flat, I'd check the load capacitor values against the crystal's datasheet-specified load capacitance, since a mismatch can prevent reliable startup even with good parts. Next I'd swap in a known-good crystal of the same part number to rule out a damaged or wrong-value crystal. If it still doesn't start, I'd try to bisect between the MCU's internal driver and the external network by feeding the clock input from an external oscillator can instead of the crystal circuit -- if the MCU then runs fine, the fault is in the crystal network; if it still doesn't run, the fault is inside the MCU or its clock configuration.

   • Identifies probe loading as a possible false negative — Answer explicitly notes that a standard 10x (or worse, 1x) passive probe's input capacitance can load a marginal oscillator enough to stop it from starting, and suggests using a higher-impedance or low-capacitance probe, or an active/FET probe.
   • Checks load capacitor values against crystal spec — Answer proposes verifying the board's load capacitors match the crystal's specified load capacitance (accounting for stray PCB capacitance) rather than assuming any value works.
   • Proposes swapping the crystal — Answer suggests substituting a known-good crystal of the same part to rule out a bad or damaged component.
   • Proposes bisecting MCU vs external network — Answer suggests driving the MCU with an alternate clock source (e.g., an external oscillator can feeding the clock input) to determine whether the MCU's internal amplifier/driver is at fault versus the external crystal network.
   • Sequences the checks logically — Answer presents the checks in a sensible order, starting with the cheapest/least destructive (probe technique, visual inspection) before moving to substitution or rework.

   Where answers go wrong: Concluding the crystal or MCU is dead without first ruling out probe loading. · Assuming the load capacitor values printed in the schematic are correct without checking against the actual crystal's spec sheet. · Not having a way to distinguish an MCU driver fault from an external crystal network fault, and guessing instead of substituting a known-good reference.

9. 9A returned board occasionally resets under vibration during shipping or handling, but it works perfectly every time you have it sitting still on your bench. Simply tapping it a few times doesn't reproduce the fault. Walk me through your strategy for making this intermittent failure reliably reproducible enough to diagnose, and what root causes you'd suspect once you can trigger it on demand.hard

   Answer this one, graded

   Or just show what a strong answer covers

   Since a fault that only appears under vibration is likely mechanical, I wouldn't just tap randomly — I'd set up a repeatable stress method, like a vibration table or a fixture that lets me apply controlled flex to the board, while continuously monitoring the power rails and reset line with a scope in a capture or trigger mode, or a data logger, so I actually catch the moment things glitch instead of just watching after the fact. Once I can reproduce the reset reliably under stress, I'd narrow it down by pressing on individual components, connectors, and suspect solder joints with an insulated tool while watching the monitored signals, to see which specific spot correlates with the glitch. My leading suspects going in would be a cracked or cold solder joint on a connector or heavy component, or a connector that isn't fully seated, since those are the classic causes of a fault that's invisible electrically at rest but appears under mechanical stress. I'd only start looking at firmware once I'd ruled out these mechanical causes, since the vibration correlation strongly points to hardware.

   • Controlled, repeatable stress method — Proposes a systematic way to apply mechanical stress (vibration table, flex test, or targeted probing) rather than relying on random tapping.
   • Continuous instrumentation during stress — States they'd monitor power rails and/or reset line continuously (scope with capture/trigger, or data logger) while stressing the board, so a brief glitch is actually caught.
   • Names plausible root causes — Suggests specific mechanical root causes such as a cracked solder joint, poorly seated connector, or a component lead under strain, rather than jumping to firmware.
   • Localization once reproducible — Describes a follow-up step of pressing on individual components or areas with an insulated tool while monitoring, to pinpoint exactly which joint or connector is the cause.

   Where answers go wrong: Tapping the board randomly without any instrumentation to catch the moment of failure. · Assuming it's a firmware bug before ruling out hardware causes given the mechanical trigger. · Stressing the whole board at once instead of trying to localize which area triggers the fault.

10. 10Two independent daughter modules connect to a main board through a shared 5V rail and connector. Neither module alone causes any problem, running for hours without issue. But whenever both are attached together, the 5V rail intermittently sags within minutes and resets both modules. Swapping in different physical units of either module doesn't change the behavior, which suggests the fault isn't in either module individually but in how the main board's shared rail responds to both loads at once. Design a rework-based test to localize the actual cause without permanently damaging any of the three boards.hard

    You have current probes, an oscilloscope, a hot air rework station, and a couple of programmable electronic loads available on the bench.

    Answer this one, graded

    Or just show what a strong answer covers

    Since swapping physical units of either module didn't change the symptom, the fault likely isn't in either module but in how the main board's 5V rail behaves under the combined load, so I'd stop testing modules and focus there. First I'd make the fault reproducible on demand: replace both real modules with two programmable electronic loads set to match their known current profiles, including any inrush spikes, and see if the sag still happens. If it does, that confirms it's a rail-response issue on the main board, not something idiosyncratic to the real modules' interaction. Then I'd put current probes on each load's feed and the main scope channel on the rail voltage, trigger on the voltage dip, and look at what the two currents were doing right before the sag -- for example, whether both loads happen to inrush simultaneously and exceed the regulator's transient response, or whether there's a shared ground return path causing ground bounce that looks like a voltage sag at the sense point. For any rework needed to separate suspect paths, like isolating the two modules' return paths from a shared ground trace, I'd do it reversibly -- cut a trace and bridge it with a removable jumper wire rather than permanently removing a component, so I can restore the board regardless of what I find. Based on what the correlated capture shows, I'd either point at insufficient bulk capacitance for the combined inrush, a marginal current limit, or a shared-impedance ground bounce issue.

    • Makes the fault reproducible with controlled loads first — Answer proposes replacing one or both real modules with programmable electronic loads matched to their known power draw profile before doing any rework, to get a repeatable test condition.
    • Uses electronic load substitution to separate rail-response from module-specific interaction — Answer explains that if the sag still occurs with electronic loads standing in for the modules, the fault is in the main board's rail/inrush/transient response rather than something unique to the real modules.
    • Proposes correlated current and voltage capture — Answer specifies using current probes on each module's feed plus a scope triggered on the rail voltage dip to see which load's current event precedes or correlates with the sag.
    • Proposes reversible, non-destructive rework — Answer specifically calls for a reversible isolation method (temporary jumper cut-and-rejoin, or lifting a pin that can be re-soldered) rather than a permanent trace cut, explicitly noting the boards must be restorable.
    • Considers a specific rail-level mechanism — Answer names at least one plausible mechanism for the main board being the culprit, such as insufficient bulk/output capacitance for combined inrush, a shared ground return causing ground bounce, or a current limit being tripped by the combined draw.

    Where answers go wrong: Immediately cutting traces or lifting pins before trying to reproduce the fault in a controlled, repeatable way. · Assuming the fault must be in one of the modules despite the swap test already ruling that out, and re-testing modules instead of the main board. · Only capturing voltage on the rail without correlating it against per-module current, so the causal event (which load, what transient) is never actually identified. · Doing permanent rework that leaves boards unusable regardless of outcome.