Electrical Fundamentals and Signal Integrity Questions

The electrical and physical-layer knowledge firmware and embedded engineers need to work correctly with real hardware. Covers voltage, current, resistance, logic levels, pull-up and pull-down configuration, clocking, and reading schematics and datasheets, as well as ensuring reliable signals across board interconnects through noise, crosstalk, timing margins, termination, and grounding. Includes debugging intermittent hardware faults with oscilloscopes and logic analyzers and connecting physical-layer issues to observable firmware and system misbehavior.

MediumTechnical

62 practiced

You suspect electromagnetic interference (EMI) from a nearby motor is causing random resets on your embedded board. Describe a practical diagnostic and mitigation plan: measurements to take with scope/logic analyzer, power-rail checks, decoupling, grounding and PCB layout fixes, shielding, and any software hardening you might do to tolerate transient disturbances.

Sample Answer

**Situation & goal** I’d confirm whether a nearby motor is causing EMI-induced random resets, then apply layered fixes: measurement, hardware mitigation, PCB/layout changes, and software hardening to tolerate transients.

**Diagnostics / measurements** - Use oscilloscope (2-channel, 100MHz+ or 1GHz if possible): probe Vcc-to-GND at MCU, VIN, and ground return while motor runs/starts/stops. Look for fast spikes (<ns–µs) and droops. - Use differential probe across motor leads and a current probe on supply to motor to see switching transients. - Trigger on resets or brownout detectable signal (GPIO toggled at boot) and capture pre-reset waveform. - Logic analyzer: capture reset pin, IRQ lines, comms (UART/SPI/I2C) to see timing with transients. - Measure conducted EMI with LISN or spectrum analyzer if available; otherwise observe with scope across chassis/connector.

**Power-rail & decoupling checks** - Verify regulators’ output and VIN during events; check ESR of bulk caps. - Add/verify local decoupling: 0.1µF ceramic across Vdd-Vss at each supply pin, 1µF–10µF MLCC bulk near regulator output. Use ferrite bead between motor supply and board. - Add 10–100µF low-ESR electrolytic on board input. Place caps as close as possible to pins, shortest traces.

**Grounding & PCB layout fixes** - Ensure single-point or star ground where appropriate; separate noisy motor return from sensitive analog/digital ground, tie at a single low-impedance point. - Short traces, avoid ground loops; enlarge ground copper under MCU and routing for return. - Route high-speed or noisy traces away from reset/Vref and oscillator. Use ground pour and stitched vias. - Add RC filter or ferrite on reset line; keep reset trace short.

**Shielding & filtering** - Add metal shielding can over MCU or motor driver if radiated EMI is the issue. - Use common-mode choke and EMI filters on I/O and power incoming lines; add TVS diodes for transients.

**Software hardening** - Enable brown-out/reset thresholds and watchdog timers with sensible timeout. - Implement debounce/retry on external interrupts and comms, persistent state saving before risky operations. - Add transient-tolerant init: on unexpected reset, wait a few ms and re-check supply rails before starting peripherals.

**Verification** - Re-run scope captures with fixes; introduce controlled worst-case motor events (start/stop, stall) and confirm no reset and reduced spike amplitude.

This layered approach locates cause, reduces coupling paths, hardens power and logic, and ensures firmware tolerates residual events.

HardTechnical

91 practiced

Metastability and input jitter cause occasional corrupted reads from asynchronous digital inputs. Describe software-level mitigations (synchronizers, double-flop, oversampling, majority voting, hysteresis), their cost in latency and CPU usage, and outline how to design tests to estimate the MTBF (mean time between failures) for metastability on your target.

Sample Answer

**High-level summary**Metastability and input jitter require trade-offs between reliability, latency and CPU. Below I list common software-level mitigations, their costs, and a testing plan to estimate MTBF for your target.

**Mitigations (what, why, cost)**- Double-flop synchronizer (2-stage FF): simple, industry standard for single-bit crossing. Latency = 2 clock cycles; CPU cost = none (hardware flip-flops). Reduces metastability escape probability by giving extra resolve time.- Multi-stage synchronizer (3+ FFs): further reduces failure probability exponentially; latency = N cycles; CPU cost = none.- Oversampling (sample input multiple times per bit using software/GPIO interrupts or ADC): increases robustness to narrow glitches and jitter. Latency = depends on sample window (often tens–hundreds µs); CPU cost = high if polling; moderate if using DMA + timer.- Majority voting (N samples, take majority): works with oversampling; extra memory/CPU to collect and compute majority; latency = sampling window length + compute (very small).- Hysteresis / Schmitt-trigger inputs: analog front-end reduces noise-induced transitions; latency = negligible; CPU cost = none if hardware; software equivalent = require stable run-length before accept (debounce) — increases latency and CPU if polled.

**Trade-offs summary**- Hardware FFs: minimal CPU, fixed latency (clock cycles).- Software oversampling/majority: flexible but high CPU and higher latency; good for low-rate signals.- Hysteresis/debounce: low CPU (if implemented in hardware); increases detection time.

**MTBF estimation (design tests + extrapolation)**1. Controlled stress: use FPGA or signal generator to create asynchronous transitions at controlled rates and adjustable timing relative to destination clock; inject worst-case pulses and jitter.2. Measure failure rate: run long-duration tests counting corrupted captures. Vary synchronizer resolve time (extra wait cycles) or sampling window.3. Fit exponential model to observed failure rate to extract device/time constant and constant K:

text

MTBF = e^(T_res / tau) / (f_input * f_clock * K)

Plain-English: increasing resolve time T_res exponentially increases MTBF; f_input and f_clock scale collision opportunities.4. Extrapolate to field conditions using measured f_input, f_clock and fitted tau, K. Include confidence intervals and run time sufficient to observe >10 failures for statistical validity or use accelerated stressing to get failures faster.5. Practical checks: use oscilloscope to capture ambiguous transitions, validate with multiple input patterns, and combine hardware (Schmitt) + 2-stage sync + optional software debounce for high-assurance.

Notes: document assumptions (clock domains, measured jitter), include safety margins (design for MTBF >> expected device lifetime).

MediumTechnical

52 practiced

An SPI peripheral returns correct data at low clock speeds but yields corrupted bytes when the clock is increased beyond a threshold. List likely electrical and software causes and propose a methodical debug approach using a scope and logic analyzer. Include potential hardware fixes (termination, series resistor, pull-ups) and software mitigations (adjust CPOL/CPHA, manage CS timing).

Unlock Full Question Bank

Get access to hundreds of Electrical Fundamentals and Signal Integrity interview questions and detailed answers.

Join thousands of developers preparing for their dream job.