All jobs / Embedded / hardware

Debugging interview questions

Debugging questions a Embedded / hardware can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. What is SWD, and how does it differ from JTAG?

    The strongest answer: Both let a debugger halt the core, step, set breakpoints and read memory. SWD does it over two pins; JTAG uses four or five and also gives you boundary scan and a chain of devices

    Why it works: Right — on a pin-tight board SWD is the usual pick, and what you give up is boundary scan and the chain.

    • Same debug job, different pin count.
    • SWD: two pins, plus optional trace out.
    • JTAG: four or five, plus boundary scan.
    • Check voltage and protocol before probing.

  2. A bug vanishes when you add printf. What did you learn?

    The strongest answer: You changed timing — I treat the print as a probe that hides races, not as a fix

    Why it works: Exactly. Heisenbugs. Prints in ISRs are a second bug.

    • Printf changes timing.
    • It is a probe, not a fix.
    • No forever ISR prints.
    • Do not ship a Heisenbug.

  3. When do you reach for a logic analyser, and when for an oscilloscope?

    The strongest answer: Analyser when the question is “are the bytes right” — many channels, a long capture, protocol decode. Scope when the question is electrical: edge shape, ringing, levels, a glitch too narrow to sample

    Why it works: Exactly — they answer different questions, and the classic mistake is decoding a line that is electrically broken.

    • Protocol questions: analyser. Electrical questions: scope.
    • Analyser: many channels, long capture, decode.
    • Scope: edges, levels, ringing, glitches.
    • A bad signal decodes as plausible nonsense.

  4. HardFault on Cortex-M. What do you capture before you “add a print”?

    The strongest answer: Stacked PC/LR and the fault status registers — then reproduce — I do not reset-in-a-loop to hide it

    Why it works: Exactly. The stacked PC is the clue. Empty handlers and -O roulette waste a day.

    • Capture stacked PC and fault regs.
    • Then reproduce.
    • Do not empty-loop the handler.
    • Do not start with -O roulette.

  5. What should a field build do on a failed assert?

    The strongest answer: A defined safe state, a log I can get, and a reset policy I chose — not a debug breakpoint instruction that hangs a kiosk

    Why it works: Exactly. Field ≠ debugger. Silent strip and BKPT hangs are two ways to fail a store.

    • Safe state + breadcrumb + chosen reset.
    • No BKPT in field builds.
    • Do not strip every assert.
    • Do not reboot with no log.

  6. Datasheet says 400 kHz I2C; the line looks filthy at 100. What wins?

    The strongest answer: The scope and the board — capacitance, pull-ups, length — I do not “trust the PDF” into a flaky field bus

    Why it works: Exactly. Physics on your PCB. Faster-into-dirt and extra MCUs are how you fail EMC and time.

    • Believe the scope on your board.
    • Pull-ups, C, length.
    • Do not outrun dirt with MHz.
    • A second MCU is not a resistor.

  7. A struct field changes value minutes into a run, and nothing in the code writes to it.

    How do you find the writer?

    The strongest answer: Put a data watchpoint on that address so the debugger halts on the write and names the culprit; where I cannot, I paint the stacks and add canaries either side and see which one is chewed

    Why it works: Exactly — a hardware watchpoint hands you the writer’s stack trace, which is the whole answer in one step.

    • Catch the write, do not chase the symptom.
    • Data watchpoint on the address first.
    • Paint stacks; read the watermark.
    • Canaries show which side overran.

  8. What do you log in the field when flash is tiny?

    The strongest answer: A ring of last resets, versions, and a few fault crumbs — I do not log every happy state until the part is worn out

    Why it works: Exactly. Crumbs you can retrieve. Happy-path floods and phone PII are two ways to fail.

    • Ring: reset, version, fault crumbs.
    • Do not flood happy-path.
    • Lab-only is not enough.
    • No user PII in MCU logs.

  9. A fleet starts resetting in the wild. First staff hour?

    The strongest answer: Halt OTA if it could be us, pull crumbs, pick a ring to inspect — I do not push a blind hotfix to 100%

    Why it works: Exactly. Stop making it worse, get crumbs, look at a ring. Blind 100% is a second incident.

    • Halt risky OTA.
    • Pull crumbs; inspect a ring.
    • No blind 100% hotfix.
    • Do not tell users to ignore resets.