EtherCAT Slave: Frame-Level Processing, Ultra-Low Loop Delay & DC Sync
← Back to: Industrial Ethernet & TSN
EtherCAT Slave is about deterministic, frame-level on-the-fly processing plus DC/SYNC timing, so cyclic PDO I/O updates stay consistent and ultra-low-latency even under real mailbox and recovery conditions.
This page explains the slave-side data paths, mapping/consistency, DC validation, delay budgeting, diagnostics, and selection logic—so systems can be built and verified with measurable jitter, WKC, and watchdog criteria.
EtherCAT Slave Overview & Boundaries
Core idea
An EtherCAT slave stays fast by letting the ESC modify process data on-the-fly while the frame passes through, and stays synchronized by using Distributed Clocks (DC) to align I/O latching and update timing.
This page covers (slave-side only)
- Frame-level cut-through processing (ESC data path, constant delay behavior)
- PDO vs Mailbox separation and governance for determinism
- DC sync quality (SYNC0/1 usage, offset/drift sanity)
- Loop delay & jitter budgeting, measurement hooks
- Slave diagnostics and controlled recovery boundaries
Not covered here (link out only)
- PHY layout/EMC/ESD/TVS/CMC (go to Protection / PHY pages)
- TSN scheduling (Qbv/Qci/GCL) and TSN switch behavior
- PTP / SyncE / White Rabbit timing stacks
- PoE / PoDL power delivery and thermal design
A. What makes a slave “fast”
The critical path is inside the ESC: the frame is parsed, matched, tapped into the process image, the working counter is updated, and the frame is forwarded without waiting for software. Software belongs on a non-critical path (application compute, mailbox services, logging) so that software jitter cannot perturb deterministic forwarding.
Engineering success metrics (placeholders)
- Incremental per-slave forwarding delay ≤ X
- Cycle-to-cycle PDO update jitter ≤ Y
- Rare latency spikes count ≤ Z per hour under load
B. Cyclic vs Acyclic in one sentence
PDO is for deterministic cyclic process data; Mailbox is for non-cyclic services and must be governed so it never steals determinism from PDO.
- Isolation: keep cyclic process image access independent from mailbox buffering.
- Governance: rate-limit mailbox throughput and bound retry behavior.
- Validation: mailbox stress must keep PDO jitter within X.
C. If you are here for X → go to Y
Keep this page lean. Topics below are intentionally routed to dedicated pages.
PHY EMI/ESD/layout → Protection (TVS / CMC / grounding)
Move PHY-side signal integrity and surge return paths out of this slave page.
TSN scheduling (Qbv/Qci/GCL) → TSN Switch / Bridge
Deterministic switching windows belong to TSN, not EtherCAT slave DC.
PTP / SyncE / WR → Timing & Sync over Ethernet
This page uses EtherCAT Distributed Clocks only.
System Roles & Data Paths (Cyclic / Acyclic in Parallel)
EtherCAT carries multiple datagrams in the same frame. The slave must support cyclic process data and non-cyclic services in parallel, while preventing non-cyclic traffic from introducing jitter into the cyclic control loop.
A. Datagram types → different KPIs
- Process data (PDO): targets fixed delay and low jitter for closed-loop control.
- Mailbox services: targets availability and bounded latency for parameterization, diagnostics, and file/objects transfer.
- Key rule: non-cyclic throughput must be bounded so cyclic jitter stays within X.
Minimal acceptance set (placeholders)
- PDO update jitter ≤ X
- Mailbox timeout rate ≤ Y per 10 minutes
- Recovery back to stable state ≤ Z
B. State machine entry points → what is allowed
INIT
Basic identity and link readiness. No application I/O updates.
PREOP
Mailbox-enabled for setup and diagnostics. PDO is not yet a controlled output loop.
SAFEOP
PDO channels are established, outputs are safety-gated. Prove mapping and DC sync here before OP.
OP
Cyclic loop runs. Mailbox must be governed (rate-limit, bounded retries) to preserve determinism.
C. Bandwidth governance → keep mailbox from perturbing cyclic
Governance is not about maximizing mailbox speed. It is about bounding impact: prevent buffer contention, limit retry storms, and keep cyclic access to the process image predictable.
Governance checklist (strategy names only)
- Rate limit: cap mailbox throughput and fragment size.
- Priority isolation: keep cyclic PDO access above mailbox service tasks.
- Bounded retries: avoid retry storms that create latency spikes.
- Watchdog policy: ensure safe fallback without oscillation.
EtherCAT Slave Architecture (ESC + MCU + PHY + Memory)
A practical slave architecture separates the deterministic cut-through datapath from the host-facing service and application path. The ESC owns frame forwarding, logical mapping, and DC timing primitives, while the MCU runs application logic, mailbox services, and diagnostics without blocking on-the-fly forwarding.
A. ESC responsibilities (deterministic engine)
- Forwarding: parse datagrams, tap process data, update WKC, forward cut-through.
- Mapping: apply FMMU/SyncManager rules to place logical addresses into the process image.
- Timing: maintain DC primitives and drive SYNC0/1 timing hooks.
What stays constant (placeholders)
- Per-slave forwarding delay ≈ X
- Datapath jitter is bounded when host access is isolated
B. MCU responsibilities (non-critical services)
- Application logic: compute control and update I/O at defined timing hooks (SYNC0/1 or cycle points).
- Mailbox stack: parameterization and diagnostics services without stealing cyclic determinism.
- Diagnostics: counters, event logs, and bounded black-box capture for forensics.
Common spike sources (name-only)
- Host bus contention / DMA starvation
- Interrupt masking / long critical sections
- Logging bursts (flash writes) in the wrong phase
C. Memory map view (process image vs mailbox vs regs)
Treat memory as separate regions with separate KPIs. The process image targets consistency and low jitter, mailbox buffers target bounded service latency, and register space targets observability and control.
Partition rules (placeholders)
- Process Image access is isolated from mailbox buffering
- Mailbox throughput is rate-limited to preserve cyclic jitter ≤ X
- Register counters are sampled with bounded overhead
What to verify next (architecture sanity)
- Cut-through forwarding remains stable when MCU load increases
- Process image and mailbox buffers do not contend under stress
- SYNC0/1 reaches the intended latch/update point with correct phase
Frame-Level Processing Pipeline (On-the-fly forwarding)
EtherCAT achieves ultra-low loop delay by overlapping processing and forwarding. The ESC parses each datagram, applies address mapping, taps process data, updates the working counter, and forwards the frame without waiting for software completion.
A. Cut-through vs store-and-forward
- Cut-through (EtherCAT on-the-fly): processing overlaps forwarding, so incremental delay per slave stays near-constant.
- Store-and-forward: forwarding waits for an entire frame, so delay grows with frame length and buffering.
B. Datagram handling steps (observable sequence)
- Parse: identify the datagram boundary and type.
- Match: select the target region via mapping rules (FMMU/SM).
- Read/Write tap: modify the process image while the frame passes.
- Update WKC: update working counter to reflect completion.
- Forward: continue forwarding without software dependency.
Primary observables
- WKC matches expected values in steady state
- Process image consistency is stable across cycles
- Delay remains within placeholder X under stress
C. Hot spots that increase delay (name + first-check)
Buffer contention
First check: process image vs mailbox buffer isolation and stress behavior.
Host stall
First check: DMA/IRQ starvation, long critical sections, and logging bursts.
Sync wait
First check: SYNC0/1 phase vs latch/update window alignment.
What to verify next (pipeline sanity)
- WKC stays consistent across cycles and matches expected values
- Delay spikes correlate with one hot-spot class, not random noise
- Mailbox stress keeps cyclic jitter within placeholder X
Process Data Mapping (FMMU / SyncManager / PDO Image)
A stable EtherCAT slave separates logical PDO space from the physical process image. The FMMU provides logical-to-physical translation, SyncManager channels enforce buffer discipline, and a clear consistency model prevents jitter spikes and stale data.
Scope guard (no expansion)
This section focuses on mapping and determinism inside the slave. PHY / EMC / isolation and timing distribution topics belong to their dedicated pages.
A. FMMU = logical ↔ physical mapping (meaning only)
- Logical space stays stable for the master and project configuration.
- Physical layout stays optimized for local RAM, alignment, and bounded access cost.
- Mapping errors are observable via expected image consistency and WKC behavior.
Fast sanity checks (name-only)
- Logical ranges cover all RxPDO/TxPDO objects
- No overlap, no unintended holes (fragmentation)
- After mapping changes: WKC and expected image remain consistent
B. SyncManager channels (buffer discipline)
SyncManager channels define how RxPDO, TxPDO, and mailbox buffers are gated and accessed. Determinism depends on keeping cyclic buffers isolated and preventing mailbox traffic from contending with the process image.
SM · RxPDO
Master writes → slave reads; access window must be bounded.
SM · TxPDO
Slave writes → master reads; update policy must avoid partial images.
SM · Mailbox
Acyclic services; must be isolated and rate-limited.
C. Consistency model (choose one, validate it)
Double-buffer
Two images (active / shadow). Swap at the cycle boundary (or defined event) to prevent partial reads.
Latch-on-event
Latch the image on a defined event (SYNC or SM event) for phase-aligned I/O snapshots.
Atomic window
Define a short window for all read/write operations; outside the window, access is blocked to preserve consistency.
Strategy selection logic (short)
- Prioritize determinism → choose Double-buffer with swap on cycle.
- Prioritize phase snapshot → choose Latch-on-event.
- Resource constrained but controlled → choose Atomic window with strict validation.
D. PDO sizing & alignment (avoid fragmentation)
- Group by update rate: keep fast cyclic objects contiguous.
- Align by word boundaries: reduce cross-boundary access and bus jitter.
- Separate mailbox buffers: avoid shared memory hot spots.
Placeholder acceptance targets
- Swap / latch completes within X
- Mailboxes do not cause cyclic jitter > X
- Expected PDO image is stable over Y cycles
Mailbox & Acyclic Services (CoE / FoE / EoE / SoE)
Mailbox is the acyclic service channel used for configuration, diagnostics, and bulk transfers. The key engineering boundary is simple: mailbox traffic may be slower, but it must remain bounded and must not steal determinism from cyclic PDO exchange.
Scope guard (no expansion)
This section explains mailbox timing policies and service boundaries. Detailed protocol internals and full stack implementation belong to dedicated stack pages.
A. Mailbox purpose & timing policy (keep it bounded)
Rate limit
Cap throughput, fragment size, and concurrent requests to protect cyclic margins.
Scheduling window
Serve mailbox within defined windows so PDO exchange remains deterministic.
Bounded retries
Avoid retry storms; enforce bounded timeouts and backoff.
Acceptance placeholders
- Mailbox service time ≤ X for typical SDO
- Mailbox stress keeps cyclic jitter ≤ X
- No retry storm: bounded retries ≤ X
B. CoE basics (SDO = engineering parameter access)
- SDO upload/download reads or writes object dictionary parameters.
- Typical use: configuration, calibration, device identity, and diagnostics fields.
- Engineering boundary: acyclic traffic is allowed to be slower, but must remain bounded and isolated from PDO exchange.
Best-practice names (no deep dive)
- Single outstanding SDO
- Chunk size cap
- Timeout budget
C. When to use FoE / EoE / SoE (scenario boundary only)
FoE
Bulk file transfer (firmware, datasets). Requires fragmentation and bounded pacing.
EoE
Ethernet-over-EtherCAT tunneling for specific integration needs.
SoE
Servo-drive oriented parameter access (scenario-specific).
D. Failure modes (symptom → first-check)
Mailbox stuck
First check: state allows mailbox, outstanding transaction completion, and reassembly buffer progress.
Timeout
First check: rate limit too strict, scheduling window starvation, and retry storm risk.
Fragmentation
First check: fragment size, concurrent requests, and reassembly buffer capacity.
Distributed Clocks (DC) Sync (SYNC0/1, Offset, Drift)
DC sync becomes practical when it is treated as a measurable control loop: offset is observed, drift is tracked over time, and SYNC0/1 provides deterministic latch and update points for I/O and control execution.
Scope guard (no expansion)
This section covers EtherCAT DC behavior and SYNC0/1 usage. PTP/SyncE timing distribution belongs to the dedicated timing pages.
A. DC model (reference, local clock, offset & drift)
- Reference clock: system time base used for alignment across nodes.
- Local clock: each slave’s DC timebase with its own short- and long-term behavior.
- Offset: phase difference at the same observation point (instantaneous).
- Drift: offset trend over time (slope), usually temperature and oscillator dependent.
Offset contributors (engineering view)
- Fixed term: topology / path asymmetry
- Thermal term: local oscillator drift
- Sampling term: timestamp tap point mismatch
- Transient term: short bursts that pollute observations
B. SYNC0/1 usage patterns (latch, update, ISR pacing)
Latch inputs
Use SYNC to define a latch window so input sampling occurs at a deterministic phase point.
Update outputs
Commit outputs on the defined SYNC edge/window to avoid “wrong-cycle” updates.
ISR trigger / pacing
Use SYNC as an ISR pacing source to reduce software scheduling jitter on the critical path.
Placeholder acceptance targets
- SYNC-to-latch jitter ≤ X
- Output commit “wrong-cycle” events = 0
- SYNC ISR period jitter ≤ X
C. Tuning knobs (tap points, filtering, topology terms)
- Timestamp tap points: align observation points with actual latch/commit boundaries to remove systematic bias.
- Filter / averaging: reduce transient noise without introducing excessive phase lag; keep response bounded.
- Topology terms: changes in path asymmetry can shift the fixed offset term; recalibration may be required after wiring changes.
Symptom → first tuning move (quick)
- Offset “jumps” after hardware changes → verify tap point and fixed-term assumptions.
- Offset looks noisy but mean is stable → increase averaging (bounded), verify transient pollution.
- Offset slowly drifts with temperature → track drift slope and validate correction behavior.
D. Validation metrics (offset stability, cycle jitter, lock behavior)
Offset stability
Track mean / peak-to-peak / percentile over Y cycles (same tap point).
Cycle-to-cycle jitter
Measure SYNC edge timing variation and the latch/commit phase error (RMS and peak).
Lock / re-lock
Validate time-to-stable after power-up and recovery under temperature and workload changes.
Ultra-Low Loop Delay & Determinism Budgeting
Ultra-low loop delay becomes repeatable when the end-to-end path is turned into a budget: each segment has a measurable delay term and a jitter term, with clear observation points for isolating bottlenecks.
Scope guard (no expansion)
This section focuses on slave-side loop delay and determinism. PHY SI/EMC, TSN shaping, and system-level PTP distribution are out of scope here.
A. Delay decomposition (wire + ESC + host + I/O)
- Wire / topology: propagation + hop accumulation (structure-driven).
- ESC path: tap/modify forwarding and local access contention (hardware-dominant).
- Host / MCU: ISR entry, data movement, application compute (software-dominant).
- I/O update: latch/commit windows and peripheral update mechanism (phase-driven).
Budget placeholders
- ESC tap delay = X, jitter = Y
- Host compute delay = X, jitter = Y
- I/O update delay = X, jitter = Y
B. Jitter sources (classify, then isolate)
Interrupt jitter
Signature: step-like phase variation. Fast check: ISR entry timestamp distribution (Pxx).
Bus contention
Signature: jitter increases with load. Fast check: correlate spikes with DMA/bus utilization events.
Memory effects
Signature: rare peaks tied to code paths. Fast check: stabilize access patterns and compare before/after.
Mailbox interference
Signature: jitter worsens during acyclic service bursts. Fast check: enable/disable bounded mailbox window and compare.
C. Measurement plan (scope points + counters + timestamps)
Scope points
SYNC0, latch/commit strobes, and output update markers to validate phase windows.
ESC counters
Frame/WKC and error counters for separating link behavior from host-side effects.
Timestamps
ISR entry/exit, image swap, I/O commit to map each budget segment to evidence.
Evidence mapping rule (short)
Every delay/jitter term in the budget must have a dedicated observation point; otherwise the budget cannot close.
D. Optimization ladder (hardware first, then software)
- Buffer discipline (double-buffer, latch/commit windows) → remove partial images.
- DMA / copy elimination → reduce CPU involvement on the critical path.
- ISR trimming → shorten and stabilize the highest-priority execution segment.
- Task scheduling last → push non-critical work outside the cycle window.
Expected improvements (placeholders)
- Peak jitter reduced to ≤ X
- Worst-case loop delay reduced to ≤ X
- Mailbox stress does not increase cyclic jitter above X
Robustness, Diagnostics & Recovery (Slave-side)
Field readiness requires a slave to make faults visible, reproducible, and recoverable. The focus here is slave-observable counters, watchdog behavior, controlled recovery, and a minimal black-box packet for fast triage.
Scope guard (no expansion)
Only slave-side visibility and recovery patterns are covered. PHY/EMC, TSN shaping, and system gateway behavior belong to separate pages.
A. Key counters (slave-observable)
WKC anomaly
Compare expected vs observed working counter. Track per-cycle and event spikes (window = Y).
CRC / frame integrity
Count integrity errors and correlate with link events to separate “application jitter” from “transport corruption”.
Port / link events
Track link up/down and event counts. Use as a fast discriminator for wiring or connector instability.
Quick threshold placeholders
- WKC anomaly events per Y cycles ≤ X
- CRC error burst length ≤ X
- Link flap count per hour ≤ X
B. Watchdogs & safe state
Process watchdog
Detect missing cyclic updates and move outputs into a defined safe policy (hold / zero / safe table).
Pass: timeout window = X, false trips = 0
Mailbox watchdog
Prevent acyclic sessions from stalling. Use bounded retry and cooldown to avoid recovery storms.
Pass: max in-flight = X, retries within budget = X
C. Recovery strategies (controlled)
Soft recovery
Use local session reset and bounded cleanup when counters spike but the AL state remains stable.
Pass: counters return to baseline within X cycles
Re-init window
Run re-initialization only inside a defined window to protect cyclic determinism and avoid cascading jitter.
Pass: re-init time ≤ X, cyclic jitter stays ≤ X
Controlled rejoin
Rejoin in stages (link → state machine → PDO participation) with rate limits to avoid recovery storms.
Pass: no network-wide flaps; stable OP within X
D. Minimal field diagnostics packet (black-box)
Keep a small ring buffer of structured snapshots. Trigger on threshold crossings, AL transitions, and watchdog trips. Avoid verbose logs on the critical path.
Identity & config
device id · firmware version · config hash
Time & cycle
cycle time · last SYNC ts · offset summary (X)
State
AL state · last transition reason · error code
Counters
WKC anomaly · CRC · WD trips · timeouts
Resource buckets
CPU load bucket · memory watermark · temperature bucket
Engineering Checklist (Design → Bring-up → Production)
This section defines a 3-gate validation SOP. Each gate has actionable checks with pass-criteria placeholders (X/Y) so it can be copied into project workflows.
Design Gate
Function
- PDO map strategy frozen (entries = X). Pass: mapping review complete.
- AL transition rules defined. Pass: state coverage = 100%.
Timing
- SYNC0/1 latch/commit windows defined. Pass: window margin ≥ X.
- Loop delay budget table drafted. Pass: all segments have owners.
Robustness
- Process watchdog + safe policy defined. Pass: false trips = 0 (target).
- Mailbox bounded policy defined. Pass: retry budget ≤ X.
Diagnostics
- Counter set defined (WKC/CRC/WD/TO). Pass: spec complete.
- Black-box schema defined. Pass: schema versioned (X).
Bring-up Gate
Function
- INIT→OP transition succeeds. Pass: success rate = 100% over X runs.
- PDO updates verified. Pass: wrong-cycle updates = 0.
Timing
- DC offset baseline captured. Pass: stability ≤ X over Y cycles.
- Loop delay segments measured. Pass: each segment has evidence.
Robustness
- Watchdog trip and recovery repeatable. Pass: recovery ≤ X and stable.
- Controlled re-init window validated. Pass: cyclic jitter ≤ X during re-init.
Diagnostics
- Snapshot trigger works. Pass: capture rate = 100% for event class X.
- Field packet exported. Pass: schema intact and parsable.
Production Gate
Function
- Regression suite frozen. Pass: X cases, pass rate = 100%.
- Config hash consistent. Pass: hash matches released baseline.
Timing
- Corner conditions validated. Pass: jitter/offset ≤ X across corners.
- Long-run stability. Pass: drift within X over Y hours.
Robustness
- Fault injection pass. Pass: recovery stable for X events.
- No recovery storms. Pass: rejoin does not cause network-wide flaps.
Diagnostics
- Field packet schema locked. Pass: schema version = X, compatibility OK.
- Counter thresholds set. Pass: thresholds validated on line (X/Y).
H2-11 · Applications (Where EtherCAT Slave Shows Up)
EtherCAT slaves appear in nodes that must exchange cyclic process data with deterministic timing. The same slave concept shows up in very different products; the pressure point shifts between sync, bandwidth, diagnostics, and the I/O update style.
Scope guard
- Only slave-side application patterns are covered here (no TSN migration, no network-wide topology tuning).
- PHY/EMC/layout details are treated as board hooks in selection logic, not expanded into a separate design guide.
Slice A
Remote I/O slice (high DI/DO density)
- Pressure points: PDO packing/alignment, consistency window, watchdog safe state.
- Slave-side choices: disciplined FMMU/SM mapping, double-buffer or latch-on-event, bounded mailbox policy.
- Verify (X): wrong-bit = 0; safe-state enter time ≤ X cycles; consistency window ≤ X.
Slice B
Servo drive control slice (tight sync loop)
- Pressure points: SYNC0/1 trigger path, ISR latency, cycle-to-cycle jitter, mailbox interference.
- Slave-side choices: hard-bounded interrupt latency, DMA-first data movement, commit window tied to SYNC.
- Verify (X): SYNC-to-output jitter ≤ X; offset stability ≤ X over Y cycles; mailbox load Z% does not increase jitter > X.
Slice C
Distributed measurement slice (latch + alignment)
- Pressure points: coherent sampling instant, latch timing, timestamp tap points, buffer watermarking.
- Slave-side choices: latch-on-SYNC sampling, monotonic timestamp capture, ring buffer snapshots.
- Verify (X): multi-channel skew ≤ X; timestamp monotonicity = pass; drop rate ≤ X per Y minutes.
Slice D
Gateway-as-slave slice (attached as a slave node)
Boundary: this slice covers slave-side cyclic + diagnostics requirements only; protocol bridging behavior is out of scope.
- Pressure points: heavy mailbox traffic, diagnostics depth, controlled rejoin without storms.
- Slave-side choices: mailbox rate limiting, black-box snapshot packet, re-init windows.
- Verify (X): mailbox timeout rate ≤ X; event snapshot capture = 100% for class X; rejoin without retry storm = pass.
H2-12 · IC Selection Logic (ESC / MCU / Interface / Isolation Hooks)
Selection must follow a measurable target: cycle time, jitter, mailbox load, and I/O update style. Examples below include concrete part numbers, but the decision tree and verify gates are the primary deliverable.
Card A · ESC (EtherCAT Slave Controller) — choose the determinism ceiling
- Key specs checklist: ports, DPRAM / process image headroom, DC / SYNC0/1 support, PDI interface latency, watchdog behavior, and diagnostics counters.
- Example ESC parts (material numbers):
- Microchip LAN9252 (ESC family example)
- Microchip LAN9253 (ESC family example)
- Beckhoff ET1100 (ESC ASIC example)
- Renesas R-IN32M3-EC (industrial Ethernet IC w/ EtherCAT slave core example)
- Texas Instruments AMIC110 (multiprotocol industrial SoC used in EtherCAT slave solutions)
- Infineon XMC4800 (MCU family example with EtherCAT integration)
- Hilscher netX 90 (multiprotocol SoC family example)
- Verify (X): cyclic path jitter ≤ X; mailbox stress at Y% does not move cyclic latency > X; required counters present (CRC/WKC/WD/timeout) = pass.
Card B · MCU / Host CPU — choose the jitter floor and diagnostics capacity
- Checklist: DMA capability, worst-case interrupt latency, memory for object dictionary + black-box log, and safe-state handling latency.
- Example MCU/SoC parts (material numbers):
- Infineon XMC4800 (MCU family example)
- STMicroelectronics STM32H743 (MCU example)
- NXP MIMXRT1062 (MCU example)
- Texas Instruments AMIC110 (SoC example)
- Renesas R-IN32M3-EC (integrated controller example)
- Verify (X): SYNC-related ISR worst-case latency ≤ X; CPU load at Y% does not increase cyclic jitter > X; snapshot record commit time ≤ X.
Card C · PDI / Host Interface — trade latency vs throughput, protect cyclic determinism
- Policy: cyclic PDO access must not stall on mailbox or diagnostics reads; use bounded service windows and non-blocking transfers.
- Interface options: SPI/QSPI-class, parallel bus-class, or integrated host-class (when ESC is integrated into the MCU/SoC).
- Verify (X): host round-trip access ≤ X; mailbox service rate ≥ X at load Y; cyclic jitter delta under mailbox stress ≤ X.
Card D · Board hooks (clock stability + isolation option) — keep it measurable
- Clock hook: select a stable reference so DC offset/drift tuning remains bounded; avoid clock noise that inflates cycle-to-cycle jitter.
- Isolation hook (optional): reserve footprints and power domains for a galvanic isolation variant; do not change signal timing paths late.
- Example isolation parts (material numbers):
- TI ISO7741 / ISO7742 (digital isolator examples)
- Analog Devices ADuM1401 (digital isolator example)
- Silicon Labs Si8642 (digital isolator example)
- Murata NXE1S0505MC (isolated DC/DC example)
- RECOM R05P05S (isolated DC/DC example)
- Verify (X): offset drift within X; reset-to-OP reproducibility = pass; isolation option build keeps jitter delta ≤ X.
Recommended topics you might also need
Request a Quote
H2-13 · FAQs (Slave-side troubleshooting only)
Scope: slave-side cyclic/PDO, mailbox services, AL state machine, DC/SYNC0/1, and host-side latency. Excludes PHY/EMC/TSN/PTP topics.
“Cycle time meets spec, but motion still jitters” — first check DC offset stability or app ISR jitter?
Likely cause: DC offset/drift not stable under load, or output update path suffers worst-case ISR latency/jitter.
Quick check: log DC offset (mean/stdev/p99) over Y cycles; capture ISR latency histogram (p99.9) and correlate jitter spikes with mailbox/diagnostic events.
Fix: bind output commit to SYNC0 window; reduce IRQ masking; move data movement to DMA; rate-limit mailbox during motion-critical windows.
Pass criteria: output-update jitter (p99.9) ≤ X; DC offset stdev ≤ X for Y cycles; missed-sync count = 0.
“WKC occasionally dips by 1 under load” — mapping overlap or SM buffer contention?
Likely cause: overlapping logical mapping (FMMU) or SyncManager buffer contention causing a missed/partial update in the process image.
Quick check: record expected WKC vs observed min WKC; validate FMMU regions are non-overlapping and aligned; read SM status/overflow indicators during the event window.
Fix: remove mapping overlaps; align PDO regions; separate cyclic PDO access from mailbox buffers; use atomic commit (double-buffer or latch) at a defined window.
Pass criteria: min WKC = expected WKC for Y cycles at load Z%; SM overflow/contend flags = 0.
“Mailbox works in PREOP, but becomes flaky in OP” — cyclic starvation or watchdog policy?
Likely cause: mailbox service is starved by cyclic load in OP, or watchdog/state policy resets mailbox progression under tight timing.
Quick check: compare mailbox timeout counters in PREOP vs OP; measure mailbox service rate (transactions/min) at cyclic load Z%; check watchdog events aligned to mailbox failures.
Fix: enforce bounded mailbox windows; decouple mailbox handling from cyclic critical path; adjust watchdog servicing order (cyclic first, mailbox bounded); avoid long critical sections in OP.
Pass criteria: mailbox timeout rate ≤ X/hour at load Z%; cyclic jitter delta vs mailbox-off ≤ X; watchdog resets attributable to mailbox = 0.
“DC sync looks good, but IO latch is late” — SYNC0 routing vs latch window?
Likely cause: latch event is triggered late (software path) or latch window is positioned after a variable-latency compute/commit stage.
Quick check: timestamp SYNC0 edge and latch event; compare latch latency distribution (p99.9) across Y cycles; confirm latch mode (hardware vs software-triggered).
Fix: latch at hardware SYNC0/1 where possible; move latch trigger into a fixed window; reduce ISR latency variance; avoid mailbox/diagnostic work near the latch window.
Pass criteria: latch latency (p99.9) ≤ X; cycle-to-cycle latch jitter ≤ X for Y cycles; late-latch count = 0.
“Works on bench, fails when many slaves chained” — propagation/processing budget exceeded?
Likely cause: end-to-end budget is exceeded when N slaves accumulate per-node processing and host-access delays, leaving no margin for worst-case jitter.
Quick check: compute budget margin = cycle time − (N×per-slave delay X) − fixed overhead; confirm failures scale with N; compare far-end WKC/min-offset vs near-end.
Fix: reduce per-node variable work (rate-limit mailbox/diagnostics), optimize host access path (DMA/non-blocking), and ensure commit windows are fixed; increase cycle time only after per-node variance is bounded.
Pass criteria: budget margin ≥ X% at N=X slaves; missed-cycle count = 0 for Y minutes; worst-case jitter ≤ X.
“SDO upload ok, download times out” — fragment size or mailbox state machine edge?
Likely cause: download path hits fragmentation/ack timing edges, or mailbox buffer occupancy blocks forward progress under OP load.
Quick check: compare upload vs download fragment sizes; log mailbox occupancy watermark; capture timeout location (segment index) and retry count over Y attempts.
Fix: reduce segment size; ensure mailbox buffers are drained in bounded windows; reset mailbox state machine on timeout with controlled backoff; avoid long blocking operations during download.
Pass criteria: download success rate = 100% for Y attempts; timeouts = 0; max retries per segment ≤ X; cyclic jitter delta ≤ X.
“After error, slave never returns to OP” — AL transition guard vs missing ack?
Likely cause: AL state transition is blocked by uncleared error cause, missing ack/handshake completion, or watchdog-latched safe state.
Quick check: read AL status and last transition error code; confirm watchdog status (process/mailbox) and whether it was cleared; verify application ready flags before requesting OP.
Fix: implement controlled re-init windows; clear root-cause flags deterministically; reset process image to safe defaults before rejoin; prevent retry storms by bounded transition attempts.
Pass criteria: recovery to OP within X seconds; no oscillation between SAFEOP/OP for Y minutes; transition error code remains 0.
“Distributed measurement timestamp mismatch across nodes” — tap point mismatch or drift filter?
Likely cause: inconsistent timestamp tap points or drift filter windows across slaves, causing systematic skew under dynamic load/temperature.
Quick check: compare timestamp capture configuration across nodes; trend inter-node delta (p99.9) across Y cycles; check whether deltas change with mailbox load steps.
Fix: standardize tap points and latch phase alignment; unify filter/averaging parameters; re-apply calibration after configuration changes.
Pass criteria: inter-node timestamp delta (p99.9) ≤ X for Y cycles; delta drift slope ≤ X per minute; mismatch events = 0.
“Loop delay low on average, but rare spikes exist” — host bus contention, cache, IRQ masking?
Likely cause: occasional host-side stalls (bus contention/cache misses/IRQ masking) or priority inversion during cyclic commit windows.
Quick check: capture worst-case ISR latency and critical-section duration; correlate spike timestamps with DMA underrun/overflow counters and mailbox bursts; confirm spike frequency under load Z%.
Fix: reduce IRQ masking; move copies to DMA; pre-allocate and pin critical buffers; throttle mailbox/diagnostics near commit; enforce strict priority for cyclic path.
Pass criteria: worst-case loop delay ≤ X; spike count = 0 per Y minutes at load Z%; cyclic jitter (p99.9) ≤ X.
“PDO data occasionally stale” — double-buffer/latching misconfigured?
Likely cause: commit ordering is not atomic, or application updates miss the intended window (double-buffer/latch mode mismatch with SM discipline).
Quick check: embed a sequence counter in PDO and detect repeats; measure application update time vs cycle; read SM status to confirm correct channel discipline.
Fix: implement atomic commit at a fixed window (double-buffer or latch-on-SYNC); ensure producer updates before commit; raise cyclic task priority; avoid mailbox work in the commit window.
Pass criteria: stale_count = 0 for Y cycles; sequence increments exactly once per cycle; update time ≤ X with margin ≥ X%.
“Firmware update via FoE fails mid-way” — mailbox bandwidth limit vs retry storm?
Likely cause: mailbox throughput is insufficient during OP load, or retries/backoff are unbounded; flash/program steps block mailbox progression.
Quick check: record FoE segment retries and timeout counters; measure mailbox service rate during update; profile flash write time per chunk and watchdog events.
Fix: reduce chunk size; slice flash writes into bounded steps; enforce bounded retry with backoff; allocate a controlled mailbox window that does not disrupt cyclic determinism.
Pass criteria: FoE success = 100% for Y images; retries ≤ X per image; timeouts = 0; cyclic jitter delta during update ≤ X.
“SYNC0 present but outputs not deterministic” — output update phase alignment wrong?
Likely cause: output update is not phase-locked to SYNC0/1, or commit occurs after variable-latency compute/locking, producing jitter despite SYNC presence.
Quick check: timestamp output update vs SYNC0 edge; build phase error and jitter histograms (p99.9) over Y cycles; confirm output mode (free-run vs SYNC-bound commit).
Fix: phase-lock output commit to SYNC window; move compute earlier; use fixed commit gate; remove blocking operations and long locks near the commit window.
Pass criteria: output phase error (p99.9) ≤ X; output update jitter (p99.9) ≤ X; stable for Y cycles with zero late-commit events.
