Silicon Bring-up · All levels
Debug Interfaces & Observability: Tricky Q&A
Senior interview and review questions for Debug Interfaces & Observability.
Section Q&A bank
Use these drills after completing all topics in Debug Interfaces & Observability. Answer with setup context, mechanism proof, artifact, owner, and release decision.
Why is boundary scan often the first high-confidence test after initial power-on, even before full firmware bring-up?
[INT][BRINGUP][DEBUG-INTERFACES]
Q: Why is boundary scan often the first high-confidence test after initial power-on, even before full firmware bring-up?
A:
Boundary scan validates physical interconnect and pin-level behavior independent of core boot readiness. It quickly separates board assembly defects and chain configuration issues from deeper silicon or software problems.
FOLLOW-UP TRAP: Skipping boundary-scan structural checks because the chip powers up and JTAG IDCODE is readable.An SWD link is electrically stable, but memory reads still return FAULT intermittently. What is the most likely bring-up mistake class?
[INT][BRINGUP][DEBUG-INTERFACES]
Q: An SWD link is electrically stable, but memory reads still return FAULT intermittently. What is the most likely bring-up mistake class?
A:
Target-state and access-context sequencing problems are common: incorrect AP selection, stale CSW/TAR programming, reset/domain timing, or debug security policy blocking transactions despite valid signaling.
FOLLOW-UP TRAP: Assuming intermittent FAULT always means signal-integrity issues on SWCLK/SWDIO.What distinguishes a useful on-chip trace setup from a noisy one during early boot debug?
[INT][BRINGUP][DEBUG-INTERFACES]
Q: What distinguishes a useful on-chip trace setup from a noisy one during early boot debug?
A:
Useful setups anchor trace to phase-specific triggers, include pre/post-trigger context, and prioritize semantically meaningful internal signals with aligned timestamps; noisy setups capture too much low-value traffic and lose causal clarity.
FOLLOW-UP TRAP: Maximizing raw trace volume without a trigger hypothesis or phase model.When should scan dump be preferred over extending ELA capture depth for an elusive bring-up hang?
[INT][BRINGUP][DEBUG-INTERFACES]
Q: When should scan dump be preferred over extending ELA capture depth for an elusive bring-up hang?
A:
Use scan dump when failures are rare, broad internal state visibility is required, or trace storage cannot span the failure interval. A frozen-state snapshot across many flops can reveal latent state divergence that narrow traces miss.
FOLLOW-UP TRAP: Believing deeper trace buffers always outperform full-state snapshots for late-occurring failures.Q&A drill guide
SYMPTOM -> ROOT-CAUSE CLASS -> ARTIFACT -> OWNER ACTION -> VALIDATIONSketch while answering
DEBUG ACCESS STACK
physical probes -> debug transport -> trace/scan capture -> correlated analysisCommon traps
Validate access-layer prerequisites before deep protocol decode.
Correlate trace timestamps with software checkpoints.
Treat missing evidence as an observability gap, not closure.
Key takeaways
Tie every bring-up claim to one reproducible setup state and one proving artifact.
Prefer bounded fixes with clear owner and rollback trigger over broad multi-variable edits.
Common pitfalls
Running parallel uncontrolled experiments and losing causality.
Declaring closure without replaying across representative corners.
Escalating severity before bench/setup hypotheses are disproven.