Electrical Fundamentals and Signal Integrity Questions

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:

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).

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.

Summary of likely causes

• Electrical: signal integrity: ringing, reflections (long traces, unterminated lines), crosstalk, poor ground return, insufficient slew control, Vcc droop when toggling, weak pull-ups on MISO/MOSI causing bus contention.
• Software/protocol: wrong CPOL/CPHA at higher edge rates, CS de-assertion timing too short, DMA/interrupt race causing bit shifts, clock stretching by peripheral not handled, insufficient SPI clock phase margin.

Methodical debug approach (scope + logic analyzer)

1. Reproduce failure at two clock rates (good vs bad).
2. Use oscilloscope on SCLK, MOSI, MISO, CS, GND:
   • Check edges, duty cycle, overshoot, undershoot, ringing, and ground bounce.
   • Measure rise/fall times and cable/trace length; look for reflections (multiple bounces).
   • Verify CS valid window covering setup/hold times.
3. Use logic analyzer to decode frames and timestamps:
   • Confirm CPOL/CPHA alignment; compare decoded bytes vs expected.
   • Check bit sampling point vs SCLK edge.
4. Correlate scope analog issues with logic decode failures to pinpoint SI vs timing bug.

Hardware fixes

• Add small series resistor (22–100 Ω) near MCU SCLK/MOSI to damp reflections.
• Add proper termination or source termination for long traces.
• Improve ground return and decouple Vcc; add ferrite bead if needed.
• Add pull-ups or pull-downs to idle lines to avoid contention.
• Shorten traces or use controlled impedance.

Software mitigations

• Try alternate CPOL/CPHA to shift sampling edge.
• Insert small delays: extend CS assert before first clock, add inter-byte CS hold, or insert NOPs before read.
• Lower SCLK or use clock divider while investigating.
• Use single-byte transfers or poll peripheral ready flags; ensure DMA/IRQ not overrunning.
• Retries/checksum and validate data at higher layers while fixing root cause.

Conclude by iterating: fix easiest (series resistor/CS timing) then re-test with scope/LA until stable.