Intent Make it immediately clear that a LIN SBC is a system policy component: LIN connectivity plus power, wake, reset, and watchdog control.

Scope guard: This page focuses on low-power policy, wake attribution, reset/watchdog strategy, and diagnostics hooks. Electrical waveform/EMC details are intentionally not expanded here.

Practical takeaways

• Think “policy enforcer.” The SBC makes power and wake behavior deterministic and testable.
• Think “serviceability.” Wake history, fault counters, and reset reasons reduce “no trouble found.”
• Think “scale.” Many small ECUs stay consistent when the same low-power and recovery policy is reused.

Intent Convert “why a LIN SBC is needed” into measurable requirements that drive selection and verification.

The highest field-risk in body/comfort nodes is rarely LIN throughput. It is usually a combination of low-power leakage, false wake patterns, and unclear reset/recovery causes.

Requirement checklist to lock before selecting parts

• Sleep budget: Iq ≤ X µA after Y seconds; define fixture/leakage control rules.
• False wakes: define the metric (per hour/day), and require wake attribution for every event.
• Reset causes: require readable reset reasons and define the “safe state” for key loads after reset.
• Logs: define N-event history depth, which counters are mandatory, and how logs are exported.

Intent Break down a LIN SBC into modules and signal paths so each block is understood by its system meaning: policy, wake control, recovery, and diagnostics.

Scope guard: This section focuses on functional paths (power, wake/policy, diagnostics). PHY waveform/EMC component details are not expanded here.

Key blocks and the system questions they answer

Bring-up mini checklist (architecture-level)

• Config readback: read and log mode/wake/WD policy registers after power-up.
• Mode loop test: run sleep → wake → sleep for X cycles; require stable Iq and consistent wake attribution.
• Reset cause sanity: induce WD and undervoltage; ensure reset reasons are distinct and retained long enough to be logged.
• Wake latch discipline: verify read/clear sequencing does not lose multi-source wake events.
• Counter usefulness: confirm that error/wake counters move with injected faults and are exportable.

Intent Define low-power behavior as a verifiable state machine: which modes exist, who can wake the ECU, and how events are retained.

The goal is not only low Iq, but predictable wake attribution, false-wake control, and no lost events across repeated sleep↔wake cycles.

False-wake control and “no lost events” discipline

Verification gates (define before implementation)

• Iq gate: sleep current ≤ X µA after Y seconds; measurement setup leakage controlled.
• False wake gate: false wake rate ≤ X/day, with each wake attributed (bus/local/timed).
• Event retention gate: wake reason and reset reasons persist long enough to be logged and exported.
• Mode loop gate: sleep→wake→sleep repeated X cycles with stable distributions and no missing entries.

Intent Make the trade-off explicit: lower battery drain versus availability and serviceability. A wake policy is complete only when each wake is qualified, attributed, and logged without losing evidence.

Scope guard: This section covers system policy paths (filter/debounce/rate-limit, latch→log→clear). It does not expand PHY waveform tuning or EMC component details.

The wake “evidence chain” (policy, not edges)

1. Trigger (bus/local/timed) →
2. Qualify (filter, debounce, minimum window) →
3. Latch reason (source attribution survives the transition) →
4. Read → log → clear (persistent history, then safe clear discipline).

Attribution discipline (wake reason that can be trusted)

Verification gates (policy-level, repeatable)

• Mode-loop: sleep↔wake repeated X cycles; wake source distribution stays stable.
• Noise/provocation: stimulate bus/local glitches; filter + debounce + backoff prevents repeated wakes.
• Race test: timed wake overlaps bus/local; attribution rules remain deterministic.
• Pass criteria: Iq ≤ X µA after Y s, false-wake ≤ X/day, completeness ≥ X%.

Intent Turn watchdog/reset from “features” into a reliability contract: detect software stalls, reset deterministically, drive loads to safe states, and preserve reset evidence for service.

Fail-safe outputs (keep loads safe during reset and recovery)

Intent Focus on system-level LIN behaviors unique to integrated SBCs: how LIN interacts with low-power modes, how the MCU controls/observes it (pins vs register control), and how fail-safe receive and bus-fault policy prevent “silent dead” ECUs.

Scope guard: PHY electrical tuning (slew rate, waveform margins, EMC component details) stays in the LIN Transceiver page. This section only covers policy paths and control/diagnostic interactions.

Control plane vs data plane (why LIN looks different inside an SBC)

• Data plane: TX/RX traffic between MCU and LIN bus (payload and scheduling).
• Control plane: wake detection, mode gating, fail-safe behavior, and status/IRQ evidence.
• Key implication: in low-power modes, the control plane often remains active while the data plane is constrained by policy.

Fail-safe receive and bus-fault policy (avoid “silent dead” ECUs)

See also: PHY electrical layer details (slew control, waveform margins, EMC sensitivity) belong in the LIN Transceiver subpage. Keep this page focused on policy + evidence + recovery behavior.

Intent Provide a minimum service dataset that survives real-world intermittency: wake history, LIN error evidence, power/thermal events, and export hooks into DTC snapshots. This converts “sporadic” into reproducible evidence.

Scope guard: Only the data flow and mapping concept are covered here. Diagnostic protocol details are intentionally excluded.

Minimum Service Dataset (MSD): the fields that unlock fast root-cause

• Wake event log: last N wakes (source + timestamp + mode before/after + sequence).
• LIN counters/timeouts: error counts and link-health evidence aligned with mode.
• Power/thermal evidence: brownout occurrences, thermal events, and reset-cause histogram.
• DTC mapping hooks: which fields become DTC summary vs extended snapshot (no protocol expansion).

Verification gates (service evidence must survive intermittency)

• Lost-evidence test: repeated sleep↔wake with forced resets; wake reason must still be recoverable.
• Counter integrity: counters monotonicity and snapshot consistency across mode changes.
• Export check: DTC summary and extended snapshot contain the MSD fields; readout succeeds ≥ X%.

Intent Provide layout hooks that matter specifically for low-power + wake-sensitive LIN SBC designs: parasitics that distort edges and trigger false wakes, placements that worsen common-mode radiation, and leakage/ground-bounce paths that break sleep Iq budgets.

Scope guard: This section avoids full component selection and EMC test methodology. For detailed device parameters and sizing, use the EMC/Protection subpage.

Hook 1 — TVS/ESD array parasitics: edges, thresholds, and false triggers (principles only)

• Edge impact: added capacitance and long stubs slow or reshape edge crossings, shrinking noise margin and increasing mis-detect risk.
• Wake sensitivity: during Sleep/Standby, wake detectors can interpret threshold “jitter crossings” as activity if parasitics create ringing near the decision level.
• Quick check: if false-wake rate increases after adding/changing TVS, first inspect stub length, cumulative protection capacitance (multi-point stacking), and the closest return path.

Hook 2 — CMC and return paths: wrong placement can be worse than none

• Core principle: a CMC reduces common-mode current only when the reference/return path is continuous and the current loop remains small.
• Failure pattern: placing the CMC far from the connector or across a broken reference plane forces common-mode currents into larger loops, increasing radiation.
• Quick check: verify plane continuity under the CMC, keep it near the port, and ensure return is not rerouted through long detours.

Hook 3 — Low-power leakage and ground bounce: the silent killers of Iq and wake integrity

• Leakage stacking: multiple protection parts and contaminated interfaces can create a non-obvious sleep-current overrun.
• Ground bounce: poor return planning can move local ground reference, creating repeated near-threshold crossings that appear as activity.
• Quick check: measure stable sleep Iq after Y seconds and correlate with wake counters/flags to detect “current + false activity” coupling.

Hook checklist (layout review, on-scope)

• TVS near the port: minimize stub and keep return short (≤ X mm placeholder).
• Avoid stacked capacitance: do not scatter multiple “helpful” protectors along the LIN line without a budget.
• CMC placement: close to connector, with continuous reference plane under the part.
• Return discipline: prevent long detours; keep common-mode loops small.
• Sleep leakage audit: sum leakage paths (port + protection + contamination risk) against Iq budget.
• Wake integrity: confirm wake detect path has stable reference in Sleep/Standby and does not float through noisy returns.

See also: Detailed component sizing, parameter trade-offs, and EMC test workflows belong in the EMC/Protection subpage. Keep this page focused on hooks that affect wake + Iq.

Intent Convert strategy into gates: design inputs, bring-up evidence, and production stability. Each item is structured as Check → How to verify → Pass criteria (placeholders).

What must be proven (repeatably)

• Low-power: Sleep/standby current meets the target after the mode is stable (Iq ≤ X µA placeholder).
• Availability: Wake works for each intended source, with correct attribution (false-wake ≤ X/day placeholder, bucketed by source).
• Reliability: Reset causes remain consistent and explainable across repeats (Top-1 cause share ≥ X% placeholder).
• Evidence chain: Each event produces retrievable records (reason latch/log + counters snapshot) for production and service.

Iq measurement pitfalls (fixture, leakage, range)

• Fixture leakage dominates: humid/dirty fixtures, probe adapters, and cable insulation can add µA–mA-level leakage at 12 V.
• Protection leakage is real: TVS/ESD parts and contamination can elevate standby current; compare with/without the protection populated.
• Auto-ranging artifacts: range switching can be mistaken as mode transitions; lock the range when possible.
• Stabilization time: measure only after the SBC declares the target mode stable and after a fixed wait (Y s placeholder).

False-wake rate: define the metric before tuning

• Denominator: fixed observation window (hours/day), ignition-off state, and temperature band.
• Numerator: wake events validated by reason latch/log (exclude deliberate test wakes).
• Bucket: bus / local / timed; track each independently to avoid “mixed” conclusions.
• Optional noise indicator: “vetoed wakes” (attempted but filtered) per day to quantify environment stress.

Reset cause consistency: read → log → clear discipline

• Read early: capture reset reason immediately after boot, before mode/policy changes overwrite context.
• Log with conditions: store VBAT-min, temperature, and mode-before/mode-after together with the cause.
• Repeatability check: over K resets, histogram the causes; drift implies measurement or policy instability.

What to probe & what to log (minimum evidence set)

• Probe: VBAT, VREG output(s), RESET/NRES, WAKE pins, LIN pin activity (presence/absence, not waveform deep-dive).
• Log: mode transitions, wake source (bus/local/timed), wake log depth N, LIN error counters/timeouts, brownout/thermal counters.
• Snapshot rule: on every wake/reset, store “counters + reason + conditions” as one atomic record.

Pass criteria matrix (placeholders)

• Sleep Iq: ≤ X µA @ (Temp band) and (VBAT band) after Y s stabilization.
• False wake: ≤ X/day overall, plus per-source limits (bus/local/timed).
• Reset causes: Top-1 share ≥ X% across K repeats; anomalies require correlated evidence fields.
• Evidence completeness: ≥ X% of wakes/resets produce a complete snapshot record.

Where LIN SBCs fit best (body/comfort small ECUs)

• Many small nodes: long ignition-off time, aggressive Iq budgets, and frequent wake/sleep transitions.
• Complex wake sources: bus + door handle/switch + sensor IRQ + timed health checks.
• Serviceability matters: wake history + reset cause + counters enable reproducible diagnosis of intermittent issues.

Selection decision tree (requirements → key specs)

1. Iq target strict? If yes, prioritize sleep/standby taxonomy + stable mode transitions + cyclic sensing support (if used).
2. Wake attribution required? If yes, require reason latch + configurable wake filters + wake log depth N.
3. Watchdog type needed? If scheduling jitter is possible, prefer window WD with controlled startup grace behavior.
4. Regulator & thermal headroom? Confirm LDO/buck capability and the ability to record/flag brownout or thermal events.
5. Diagnostics hooks needed? Require counters + export path (MCU snapshot → DTC/service), not just a raw status pin.

Common failure patterns that selection must prevent

• Sleep current “mystery high”: policy not fully entering sleep, cyclic sensing misconfigured, or protection leakage not accounted.
• Wakes but no evidence: reason latch not read early, log not retained, or counters not snapshotted per event.
• Reset storms: watchdog choice mismatched to software timing, or brownout events not handled as first-class evidence.

Concrete material numbers (examples — verify package/suffix/availability)

Sleep Iq is low, but the vehicle still over-discharges overnight—first check “who woke it” or “leakage”?

Likely cause: wake events (bus/local/timed) are occurring, or the measurement setup hides a leakage path that only appears over long time.

Quick check: read wake reason latch + wake log (last N events) and correlate with time window; repeat Iq measurement with a known-clean fixture and record VBAT/Temp.

Fix: tighten wake filters/debounce and rate-limit wake retries; add “snapshot-on-wake” logging; validate protection/fixture leakage by A/B build (with/without suspect parts).

Pass criteria: Sleep Iq ≤ X µA after Y s stabilization AND false-wake ≤ X/day (bucketed) AND wake log shows ≤ X unintended events overnight.

False wakes cluster on rainy/humid days—first check wake-pin debounce or harness leakage paths?

Likely cause: humidity-driven leakage/contamination shifts thresholds or injects micro-currents; debounce/filter settings are too permissive for that environment.

Quick check: compare false-wake/day vs humidity; inspect whether “vetoed wakes” increase; read wake source bucket (local vs bus) to identify the entry point.

Fix: raise debounce time / add multi-sample qualification; harden wake input policy (rate-limit + backoff); add contamination/leakage screening in service or production gates.

Pass criteria: false-wake ≤ X/day across humidity band AND vetoed-wake ≤ X/day AND wake attribution remains consistent (≥ X% correct bucket).

LIN bus looks “quiet,” but the ECU still wakes periodically—timed wake or header-noise trigger?

Likely cause: timed wake/health-check policy is active, or bus-wake detection is too sensitive and interprets sporadic activity as a wake pattern.

Quick check: read wake attribution (timed vs bus) from latch/log; temporarily disable timed wake and observe whether wake cadence disappears over a full window (hours).

Fix: correct timed-wake schedule and retention rules; tighten bus-wake qualification (pattern + debounce) and ensure logs snapshot counters per wake.

Pass criteria: timed wake occurs only at defined intervals (±X%) OR bus-wake rate ≤ X/day; wake log shows consistent source for ≥ X% of events.

Watchdog resets happen occasionally, but application logs look clean—window config or kick-timing jitter?

Likely cause: window watchdog margins are too tight for real scheduling jitter (especially after wake), or the startup grace period is not aligned with boot timing.

Quick check: log early/late/missed-kick counters (or equivalent status) around resets; measure kick interval histogram and compare against window bounds.

Fix: widen the watchdog window or move kick to a deterministic scheduler slot; add post-wake grace and “read-reset-cause-first” discipline before policy changes.

Pass criteria: WD resets ≤ X per Y hours under worst-case load AND kick jitter stays inside [window_min, window_max] with ≥ X% margin.

Reset reason is always reported as “POR”—latch not retained or register read timing wrong?

Likely cause: reset-cause latch is cleared too early, overwritten by a second reset, or read occurs after the system reconfigures the SBC state.

Quick check: enforce a boot rule: read reset cause as the first operation, log it with VBAT/Temp, then clear; compare results across repeated reset injections.

Fix: reorder initialization (read→log→clear before mode transitions); add “double-reset detection” (count resets within T seconds) to avoid mislabeling as POR.

Pass criteria: reset cause matches injected fault (POR/BOD/WD/thermal) with ≥ X% accuracy across K repeats; “POR-only” rate ≤ X%.

After waking from sleep, LIN communication occasionally times out—mode transition delay or MCU init order?

Likely cause: LIN interface is not fully enabled when the MCU starts messaging, or the MCU config sequence enables traffic before applying policy and clearing stale status.

Quick check: timestamp mode transitions and first LIN activity; verify a deterministic sequence: read status → configure policy → enable LIN → start traffic.

Fix: add a post-wake settle delay (T ms placeholder) before bus activity; gate application traffic on “LIN-ready” status; snapshot counters on every timeout.

Pass criteria: wake-to-first-valid-LIN ≤ X ms with 0 timeouts over Y wake cycles; timeout counter growth ≤ X per day.

At cold temperature, Iq rises and false wakes increase—how to prove which pin/module drifted?

Likely cause: temperature changes leakage paths, wake-input thresholds, or mode stability; a specific wake source becomes more sensitive and triggers extra wake cycles.

Quick check: run a cold vs room A/B: record Iq, wake source histogram, and vetoed-wake counts; disable one wake source at a time to isolate the trigger.

Fix: tune debounce/filters for cold; enforce stricter wake qualification; add per-source backoff; verify mode entry/retention timing at cold VBAT.

Pass criteria: cold Iq ≤ X µA and false-wake ≤ X/day AND wake histogram remains stable (±X%) across cold/room corners.

Production tests pass, but the customer sees intermittent “hangs”—which three event classes must the black box record first?

Likely cause: the field issue is a rare interaction among wake events, resets, and bus faults that production windows did not cover.

Quick check: ensure the system records (1) wake events with attribution, (2) reset cause histogram, (3) LIN counters/timeouts snapshots—each with VBAT/Temp/mode tags.

Fix: implement “snapshot-on-wake/reset” atomic records; export to DTC/service readout; add a watchdog-safe-mode path for recovery.

Pass criteria: evidence completeness ≥ X% over Y days AND field reproduction yields a consistent root-cause bucket within N events.

Adding a TVS makes false wakes worse—is it leakage or threshold-crossing jitter?

Likely cause: added leakage (temperature/humidity dependent) elevates standby current and shifts wake detection, or added parasitics increase sensitivity near thresholds.

Quick check: A/B compare with/without TVS: (a) Sleep Iq delta, (b) wake histogram by source, (c) humidity/temperature correlation of wake attempts (vetoed-wake).

Fix: tighten wake qualification/filters; move policy to prefer local wake validation; validate leakage across corners and update the production gate to screen it.

Pass criteria: TVS-added Iq delta ≤ X µA AND false-wake delta ≤ X/day across corners; wake attribution remains stable (≥ X%).

Wake attribution is inconsistent (bus/local mixed)—latch clear strategy or interrupt race?

Likely cause: multi-source wake arrives close in time and software clears/reads latches in the wrong order; concurrent interrupts overwrite a single “last-cause” field.

Quick check: enforce “read-all-sources then clear” and log timestamps; verify that latch read happens before enabling secondary wake sources post-boot.

Fix: implement a deterministic priority rule (bus/local/timed) and store a bitmask of sources; clear latches only after snapshot is committed.

Pass criteria: attribution accuracy ≥ X% across Y injected multi-source tests; “unknown/mixed” bucket ≤ X%.

After ECU reset, a critical load state is wrong—how to check fail-safe default and power-up sequencing?

Likely cause: fail-safe output default state does not match the safety assumption, or the load is enabled before MCU policy config completes after reset.

Quick check: capture reset cause + timestamp, then probe reset pin and load-enable signal ordering; confirm which state outputs assume during reset and early boot.

Fix: enforce safe defaults in hardware and lock the load until policy and diagnostics are configured; add a post-reset sequencing checklist and regression test.

Pass criteria: for K resets, load state always enters defined safe state within X ms and transitions only after policy-ready (0 violations).

Same software, different SBC model: false wakes differ a lot—what 3 mode-related configs must be aligned first?

Likely cause: default policy differs by SBC: wake filters, latch/clear behavior, and mode entry/retention differ even if the LIN function appears compatible.

Quick check: compare (1) mode taxonomy/entry conditions, (2) wake qualification/filter/debounce, (3) latch/log clear + snapshot timing; validate with identical test window.

Fix: standardize a policy profile across SBCs; enforce read→log→clear order; gate wake enablement until policy is applied; add a cross-SBC regression suite.

Pass criteria: false-wake difference between SBC variants ≤ X/day under the same conditions; attribution accuracy ≥ X%; evidence completeness ≥ X%.