This document is for product evaluation. For wiring, PDO/SDO fields, FoE compatibility, For configuration and troubleshooting, use the ECAN-Lite Application Manual V3.0. For protocol and object definitions, use the ECAN-Lite Technical Reference V3.0. Source customers should start with the source quick start.

What Problem Does It Solve?

Many field devices still use CAN or CAN FD while control systems are converging on EtherCAT. ECAN-Lite bridges the two networks:

How Data Flows

Core Capabilities

Quick Specifications

Validated real-time operating modes

The current Linux/IgH delivery is converged to two modes:

The examples apply the period, PDO size, phase, and send strategy as one profile, so users do not need to reconstruct the parameter combination. Actual latency still depends on the host, kernel, NIC, CAN bit rate, bus load, and motor response time; validate the complete deployment as described in the technical manual.

In-Robot Communication and Debugging

Robot systems often include joint drives, end-effectors, torque sensors, grippers, I/O modules, and safety components. These devices may be distributed across several CAN buses and may use CANopen or vendor-specific protocols. ECAN-Lite acts as a real-time conversion layer between the robot controller and the internal CAN network, aggregating distributed CAN traffic into EtherCAT.

Which applications are suitable?

Why is it easier to integrate?

Delivery Features

Release File Boundaries

The <release-id> in ecan_demo_app_raw_<release-id>.bin inside ECAN-DEMO-firmware-<release-id>.zip matches the delivery package and makes the image traceable to its source revision. The image retains the public CoE object dictionary, including 0xF000:00, 0xF000:05, and 0xF000:06, but is intended only for direct programming with a programmer/debugger or in a production-test flow.

Typical workflow

Pre-integration checklist

ECAN-Lite Application Manual V3.0

For first connection, master configuration, CAN/CAN FD transfer, cycle selection, IgH integration, upgrade, and field troubleshooting. For the complete object dictionary, bit definitions, wire formats, and capabilities, see ECAN-Lite Technical Reference V3.0.

[TOC]

1. Start here

You do not need to learn the full protocol before using the module. Complete one verifiable frame first, then add capacity, channels, CRC, DC, or diagnostics only when the project needs them.

Figure 1. Recommended path: build a minimal closed loop before adding features.

1.1 Choose a baseline

!!! important "Capability is not the active default" Firmware 2.x means that V2 is supported; it does not automatically select V2. For legacy-master compatibility, the factory/reset baseline may still be V1 with CRC off (0x04). A new master should read capabilities, then explicitly select V2 with CRC off (0x24).

1.2 The five things that must be configured

!!! note "Direction names" EtherCAT directions are named from the master. RxPDO goes from the master to ECAN-Lite and is transmitted on CAN. TxPDO returns from ECAN-Lite to the master and originates on CAN.

1.3 Preflight

• The released ESI matches the product and the slave reaches PREOP.
• CAN_H, CAN_L, ground, and termination are correct; the peer supports CAN FD ISO and BRS.
• Configuration SDOs are written in PREOP/SAFEOP and every Apply Status is checked.
• First bring-up uses one slave, one channel, and one fixed test frame.
• In OP, observe WKC, a CAN analyzer, and module status together.

2. Send the first frame in ten minutes

This reproducible baseline uses slave 0, CAN0, V2, CRC off, standard ID 0x123, CAN FD+BRS, DLC 8, and data 11 22 33 44 55 66 77 88.

2.1 Follow the data

Figure 2. Write RxPDO to transmit CAN; read TxPDO to receive CAN.

2.2 Confirm V2 capability

Read in PREOP:

sudo ethercat upload -p 0 -t uint16 0xF000 0x05
sudo ethercat upload -p 0 -t uint16 0xF000 0x09
sudo ethercat upload -p 0 -t uint32 0xF000 0x16

Use V2 only when all three checks pass:

If any check fails, use V1 with CRC off (OptionFlags=0x04) and the V1 codec.

2.3 Select V2, disable CRC, and allow CAN0

0x8010 configures TxPDO, module to master. 0x8011 configures RxPDO, master to module. Write fields first and :01=1 Apply last.

# TxPDO: V2 + NO_CRC16, CAN0
sudo ethercat download -p 0 -t uint8 0x8010 0x04 0x01
sudo ethercat download -p 0 -t uint8 0x8010 0x07 0x24
sudo ethercat download -p 0 -t uint8 0x8010 0x01 1

# RxPDO: V2 + NO_CRC16, CAN0
sudo ethercat download -p 0 -t uint8 0x8011 0x04 0x01
sudo ethercat download -p 0 -t uint8 0x8011 0x07 0x24
sudo ethercat download -p 0 -t uint8 0x8011 0x01 1

# Both must return 0
sudo ethercat upload -p 0 -t uint8 0x8010 0x02
sudo ethercat upload -p 0 -t uint8 0x8011 0x02

0x24 = HEADER_V2(bit5) + NO_CRC16(bit2). It is the recommended new-project selection, not an automatic V2 default.

2.4 Configure CAN0 for 1M + 5M

sudo ethercat download -p 0 -t uint32 0x8001 0x13 1000000
sudo ethercat download -p 0 -t uint32 0x8001 0x14 5000000
sudo ethercat download -p 0 -t uint8  0x8001 0x01 1
sudo ethercat upload   -p 0 -t uint8  0x8001 0x02

0x8001:02 must return 0. The minimal path keeps Normal mode, CAN FD ISO, TDC enabled, and automatic timing. Configure exact sample points only when the peer requires them.

2.5 Build the V2 first frame

On a 4-channel device, V2 uses a 16-byte header followed by CAN_FRAME records. The first 28 bytes are shown below; fill the remainder of the PDO with zero.

# V2 header, 16 bytes
24 00 01 00 01 00 0C 00 00 00 A1 04 00 00 00 00

# CAN_FRAME, 12 bytes: CAN0, FD+BRS, DLC8, ID 0x123, 8-byte payload
40 03 23 01 11 22 33 44 55 66 77 88

!!! warning "Advance the sequence" For each new PDO image, seq_begin and seq_end must be equal and advance together. Unequal values mark an update in progress; an unchanged completed image is idempotent and is not transmitted again.

2.6 Prove that it worked

1. The slave is OP and domain WKC remains stable.
2. A CAN analyzer sees ID 0x123, FD, BRS, DLC 8, and exact payload.
3. After the peer returns a frame, TxPDO payload and frame count change.
4. 0x8001:02, 0x8010:02, and 0x8011:02 remain 0.
5. Run at least ten minutes before adding channels or load.

In 0x24, bit 0 is reserved and must remain zero; firmware rejects 0x25. Confirm application completion through the CAN peer response, and diagnose local congestion or bus errors through PDO channel status and SDO diagnostics.

3. Add only what the project needs

Change one class of parameters at a time. Read Apply Status and save the active configuration after each change.

3.1 Add channels

Channel-mask bits 0..7 correspond to MCAN0..7. Change 0x8010/0x8011:04, then Apply. The CH field in each frame still chooses the output; a mask is not a broadcast command.

3.2 Set exact sample points

For nominal 1M at 76.5% and data 5M at 88.2%, disable automatic timing and set each minimum and maximum to the same value:

sudo ethercat download -p 0 -t uint8  0x8001 0x07 0
sudo ethercat download -p 0 -t uint32 0x8001 0x13 1000000
sudo ethercat download -p 0 -t uint32 0x8001 0x14 5000000
sudo ethercat download -p 0 -t uint16 0x8001 0x15 765
sudo ethercat download -p 0 -t uint16 0x8001 0x16 765
sudo ethercat download -p 0 -t uint16 0x8001 0x17 882
sudo ethercat download -p 0 -t uint16 0x8001 0x18 882
sudo ethercat download -p 0 -t uint8  0x8001 0x01 1
sudo ethercat upload   -p 0 -t uint8  0x8001 0x02

An Apply Status of 0x04 is a failure, not a configured value of four. Typical causes are an unrealizable integer timing solution, wrong write order, Message RAM conflicts, or values that do not apply to the current MCU.

3.3 Adjust PDO size

V2-capable firmware encodes coarse and fine size in an existing 8-bit selector, so no new SDO or SSC regeneration is needed:

PDO_bytes = coarse × 128 + fine × 16
selector  = (fine << 5) | coarse

!!! important "Three sizes must match" ESI PDO/SM size, registered master-domain size, and firmware Active PDO bytes must be identical. Check 0xF000:16 bit7 before using fine sizing. A legacy IgH master that writes only the low five bits still gets the original 128-byte multiples.

The total process image for multiple slaves must also fit the actual Ethernet/EtherCAT frame budget. Validate the generated frame length, WKC, and cycle jitter rather than summing nominal slave maxima.

3.4 Choose V1, V2, and CRC

Figure 3. V2 lowers fixed overhead; V1 remains available for deployed masters.

With CRC off, incoming payload CRC is not checked and the reported value is 0. When CRC is enabled, both ends must use the same algorithm and coverage. EtherCAT FCS, CAN CRC, and PDO payload CRC are separate mechanisms.

3.5 Profiles, budgets, and results

Always write fields, write Apply last, read Apply Status, read active values, then enter OP. Do not Apply repeatedly from the real-time loop.

4. Select cycle mode and load

4.1 Select by goal

Figure 4. SM exchanges both directions each subcycle; DC assigns a deterministic processing window.

4.2 Measure after estimating

CAN FD frame time includes arbitration, control, stuffing, CRC, ACK, and intermission. Do not calculate it as 8 bytes ÷ 5 Mbit/s. Two frames per channel in each 250 µs subcycle means eight frames per channel per millisecond, plus MCAN service, PDO parsing and packing, PDI access, multi-slave frame length, master jitter, peer latency, and retries.

4.3 Overload may drop frames but must recover

A passing overload test proves that the configured drop policy is visible, queues do not become permanently blocked, bus-off is recoverable, rated throughput returns within the limit, CAN overload does not leave EtherCAT WKC abnormal, and repeated overload/recovery runs behave consistently.

5. Integrate with IgH

5.1 Keep protocol details behind APIs

!!! important "Do not hand-code two layouts" One application may support V1 and V2, but a single codec should build the active format. Read capabilities and use the protocol-selection API; a version string beginning with 2 is not sufficient by itself.

5.2 Initialization and cyclic order

request master → create domain → create slave configs
→ read/validate capabilities → select V2 + CRC off (or V1 fallback)
→ configure PDO and MCAN → register PDO entries → configure SM/DC
→ activate master → start cyclic loop

receive → domain_process → read TxPDO → build/write RxPDO
        → domain_queue → sync clocks if DC → send

Do not perform SDO Apply, dynamic allocation, heavy logging, or blocking waits in the real-time loop.

5.3 SM, DC, and test peers

Use absolute-time scheduling for the 250 µs SM loop and monitor application latency, WKC, and missed cycles. In DC mode, update application time every cycle, synchronize reference/slave clocks at a fixed cadence, and keep the 1 ms period aligned with the 900 µs Sync0 phase.

• First bring-up: one slave, SM, V2/no-CRC, CAN0.
• Throughput: slaves 1+2 self-loop, then add slave 0 and UCAN.
• Final system: validate the actual PDO combination and host load.
• Use the project Rust UCAN driver as the default test peer; SocketCAN is not the reference baseline.

5.4 Coexistence and records

When CiA402 and ECAN-Lite share a loop, record each domain WKC separately, prevent CAN logging or replies from blocking the motion state machine, keep layouts fixed in OP, and test combined frame length, CPU use, and worst-case execution time.

Record firmware/build/capabilities, ESI and SM sizes, demo parameters, CPU affinity, scheduler, NIC/master version, peer-driver version, duration, and complete statistics for every reproducible run.

6. Troubleshoot, upgrade, and maintain

6.1 Separate fault layers first

Figure 5. Separate WKC, configuration status, and CAN content before changing parameters.

6.2 Common symptoms

6.3 WKC isolation

1. Remove CAN pressure and keep a fixed PDO image.
2. Compare master domain, SM2/SM3, and Active PDO bytes.
3. Reproduce with one slave, 256-byte PDO, and a slower cycle.
4. Confirm every receive/process/queue/send step runs each cycle.
5. Add slaves, target period, and load one at a time.
6. Investigate CAN loss only after WKC is stable.

Preparing the next image from the previous cycle does not eliminate ESC/PDI ownership, access-window, application-cycle, or worst-case execution constraints.

6.4 FoE upgrade

1. Record old firmware, product, and configuration; use a packaged application image matching the bootloader and MCU family.
2. Stop the cyclic application and enter the allowed upgrade state.
3. Upgrade each slave separately and save complete logs.
4. Power-cycle and read version, build, and capabilities.
5. Run a V1/no-CRC compatibility smoke test, then explicitly enable V2/no-CRC.
6. Regress PDO sizes, CRC on/off, single/multiple channels, SM/DC, and overload recovery.

6.5 Acceptance evidence

Appendix A: Minimal quick card

A.1 Recommended new-project path

capability passes → 0x8010/0x8011:04 = 0x01
                  → 0x8010/0x8011:07 = 0x24
                  → Apply each; status must be 0
                  → CAN0 = 1M + 5M; Apply status must be 0
                  → write V2 first frame; advance both sequence fields

A.2 Legacy fallback

V1 + CRC off: OptionFlags = 0x04
Keep the legacy PDO size and codec
Do not auto-select V2 merely because firmware is 2.x

A.3 First frame

24 00 01 00 01 00 0C 00 00 00 A1 04 00 00 00 00
40 03 23 01 11 22 33 44 55 66 77 88

Appendix B: Key-object quick reference

Search the Technical Reference global object index for complete subindices, types, ranges, error codes, and capability bits.

Appendix C: Compatibility matrix

Appendix D: Document boundary and revision

This Application Manual answers how to configure and run the product quickly. The Technical Reference defines every field, valid value, and error. V1/V2 differences are concentrated in the PDO header and its selection; the rest of the product remains one functional system.

ECAN-Lite Technical Reference V3.0

This manual completely defines the product architecture, EtherCAT/CAN FD protocol, PDO byte layout, frame encoding, object dictionary, defaults, and diagnostics. For wiring, master configuration, IgH examples, FoE update, operation, troubleshooting, and acceptance, see the ECAN-Lite Application Manual V3.0.

[TOC]

1. Product positioning

ECAN-Lite is an EtherCAT-to-CAN/CAN FD real-time gateway slave. The master issues transmit requests through RxPDO and reads received frames, transmit results, and channel status through TxPDO.

Periodic data uses a fixed header followed by a continuous frame stream:

VersionedFixedPdoFrameHeader + FramePacketStream[ActivePDOBytes - HeaderBytes]

The fixed header self-describes its format and length through ver_ihl. CAN/CAN FD packets follow in the continuous frame area. Chapters 4 and 5 define PDO sizing, header formats, and capabilities.

!!! important "Normative language" Must identifies a protocol requirement, should identifies a recommended implementation, and may identifies an optional capability. Object definitions, bit fields, defaults, and limits are normative here; operational procedures are defined in the Application Manual.

2. Core features

3. Direction definition and system architecture

TxPDO and RxPDO are independent directions. PDO size, channel mask, encapsulation profile, budget policy, and direction options can be selected separately.

Channel enable and PDO length do not replace each other. Disabling a CAN channel changes only the active channel mask and scheduling budget; it does not change SM2/SM3 length.

It is useful to read the protocol in three layers:

For first traffic, follow Application Manual Chapter 1. A custom PDO codec must implement Chapters 4 through 11 of this manual.

!!! warning "Direction mistakes can fail silently" RxPDO/SM2 is written by the master and read by the slave. TxPDO/SM3 is written by the slave and read by the master. Process-image registration, buffer names, and send/receive APIs must preserve this definition.

3.1 Document markup description

The following tables in this article use the following notation:

Access in the PDO table refers to the master's access method for process data: RxPDO/SM2 is written by the master and read by the slave; TxPDO/SM3 is written by the slave and read by the master.

3.2 System architecture

EtherCAT Master
  |
  |  SM2 RxPDO: Fixed Header + FramePacketStream
  |  SM3 TxPDO: Fixed Header + FramePacketStream
  v
+------------------------------+
| ECAN-Lite EtherCAT Slave     |
|  SSC + CoE + FoE             |
|  Dynamic PDO Parser/Packer   |
|  Byte Budget Scheduler       |
+-----+-----+-----+-----+------+
      |     |     |     |
     CAN0  CAN1  CAN2  CAN3

4. EtherCAT PDO mapping and size

4.1 128B Chunk Mapping

PDO mapping is assembled from 128B chunks. Each chunk is split into 8 STRING(16) mapping units in the object dictionary to avoid the bit-length limit of a PDO mapping entry.

RxPDO chunk maps: 0x1600..0x1617
TxPDO chunk maps: 0x1A00..0x1A17
SM2 assignment: 0x1C12 selects the first N RxPDO chunks
SM3 assignment: 0x1C13 selects the first N TxPDO chunks

A chunk is an EtherCAT mapping and length-selection unit, not a protocol parsing layer. The base area uses complete 128B chunks. If fine sizing is requested, one tail mapping is appended and only its first fine 16B entries are enabled. FramePacketStream may span those boundaries; the receiver parses only the valid frame area described by payload_len.

!!! danger "PDO assignment must match the active length" The effective bytes mapped by 0x1C12/0x1C13 must equal ActivePDOBytes in the corresponding direction. A mismatch rejects the profile and may prevent OP. Never change the PDO length while the slave is in OP.

4.1.1 How the master assembles multiple chunks

On the master side, do not treat 0x1600..0x1617 / 0x1A00..0x1A17 as multiple independent protocols. They are only 128B mapping blocks used to satisfy EtherCAT PDO mapping limits. The application should combine the first N chunks in the same direction into one continuous byte buffer in assignment order:

RxPDO/SM2 output buffer:
  chunk0[128B] + chunk1[128B] + ... + chunkN-1[128B]
  "..." means the omitted chunks continue in the same order, 128B each

TxPDO/SM3 input buffer:
  chunk0[128B] + chunk1[128B] + ... + chunkN-1[128B]
  "..." means the omitted chunks continue in the same order, 128B each

Each 128B chunk contains 8 STRING(16) mapping units. If the master exposes them as separate variables, copy them in the following order:

for chunk = 0 .. N-1:
  for unit = 0 .. 7:
    dst_offset = chunk * 128 + unit * 16
    copy 16 bytes to/from process image entry

The following table expands the 8 mapping units of chunk=0 and shows the first unit of chunk=1. All later chunks follow the formula below.

Complete mapping rules:

General formula:

unit_index = chunk * 8 + unit
offset     = unit_index * 16

RxPDO data object index = 0x7000 + unit_index * 0x10
TxPDO data object index = 0x6000 + unit_index * 0x10

So chunk=1 is not only unit=0. For example, RxPDO 0x1601 contains eight 16B units: 0x7080, 0x7090, ..., 0x70F0. TxPDO 0x1A01 contains 0x6080, 0x6090, ..., 0x60F0. In both examples, ... only omits the middle objects that increase by 0x10.

For example, when N=3, the continuous buffer in each direction is 384B:

chunk0: offset   0..127
chunk1: offset 128..255
chunk2: offset 256..383

The versioned header is located at offset 0 of the continuous buffer. The frame area starts at HeaderBytes=4*(ver_ihl&0x0F) and ends at ActivePDOBytes-1. The factory default is V1 (24B on HPM5E and 32B on HPM6E); explicitly selected V2 is 16B/20B. CAN_FRAME packets may cross a chunk or tail boundary. The master must use payload_len, the applied profile and the optional CRC field to determine the valid area.

In TwinCAT, CODESYS, or a custom master, if the tool can map PDO data to a continuous byte array, create ARRAY[0..ActivePDOBytes-1] OF BYTE. If the tool exposes each STRING(16) as a separate variable, assemble and split the data in the application layer using the offset formula above.

4.2 Relationship between total PDO length and header overhead

Total PDO length and fixed-header version are independent configuration dimensions, but together they determine the space available for CAN frames:

SIZE (0x8010/0x8011:03) --> ActivePDOBytes (total PDO length)
VERSION (0x8010/0x8011:07 bit5) --> HeaderBytes (header length)

ActivePDOBytes - HeaderBytes --> ActiveFrameAreaBytes (usable area)

ASSIGN (0x1C12/0x1C13) == ActivePDOBytes
IHL (ver_ihl.IHL) --> actual HeaderBytes at runtime

!!! important "Length and header version are independent" Changing the header version does not change SM2/SM3 length or require rebuilding the PDO assignment. It changes only the frame-stream offset and usable bytes. Changing total PDO length does not select another header version, but it does require matching EtherCAT mapping changes.

4.2.1 Size field: backward-compatible 5+3 encoding

base = PdoSizeEncoding & 0x1F
fine = PdoSizeEncoding >> 5
ActivePDOBytes = 128 * base + 16 * fine
ECAN-Lite: base=1..10, fine=0..7

The requested values at 0x8010/0x8011:03 both default to 0x02, or 256B. The low 5 bits select complete 128B base chunks. When capability-gated, the high 3 bits append 0..7 tail units of 16B. Legacy masters writing 1..10 keep a zero high field and therefore retain the original 128B steps.

Use a nonzero fine field only when 0xF000:16 bit7 FINE_SIZE_16=1. When fine>0, 0x1C12/0x1C13 must assign the first base complete chunks plus a tail mapping whose first fine 16B entries are enabled. This read-only capability is not a configuration switch.

4.2.2 Actual frame area for the same total PDO length

The table separates total process-image length from protocol overhead. Each frame-area value is ActivePDOBytes-HeaderBytes:

V2 gains frame space by compressing the fixed header: 8B per PDO image on 5E and 12B on 6E. The total EtherCAT PDO byte count does not change. Chapter 5 lists the removed fields and reduced status precision; do not switch versions only to gain a few bytes without confirming master-codec support.

4.2.3 Effect of each configuration change

4.2.4 Capability checks and active readback

Check the following objects before and after configuration; a successful requested-SDO write alone is not sufficient:

Recommended sequence:

1. Read capabilities.
2. Select total length and construct the mapping.
3. Select the header version and apply.
4. Read :02 and :09..12.
5. In OP, calculate HeaderBytes from ver_ihl in every image.

!!! caution "Capacity is not real-time performance" A larger PDO increases process-image capacity, EtherCAT frame length, and PDI copy work. Validate WKC, cycle jitter, and drop counters with the target cycle, slave count, and CAN load.

4.3 ESI and PDO mapping requirements

Use the ESI file supplied with the product release and do not modify the device SII/EEPROM. The actual PDO length used by the master is determined by the first N chunks selected by the 0x1C12/0x1C13 assignment and must match the active profile at 0x8010/0x8011. If the ESI, device firmware, and master configuration versions do not match, restore the matching release package and contact technical support.

5. PDO fixed header

TxPDO and RxPDO use the same version rules. ver_ihl stores the version in the high nibble and the number of 4B words in the low nibble. OptionFlags.bit5=HEADER_V2 selects V2; clearing it selects V1. The factory, reset, and current IgH default is OptionFlags=0x04 (V1 plus NO_CRC16); the master must set bit5 explicitly for V2. HPM5E uses 0x24/16B for V2 and 0x16/24B for V1; HPM6E uses 0x25/20B and 0x18/32B.

The first 12 bytes are common: ver_ihl, flags, seq_begin, seq_end, payload_len, payload_crc16, and layout_id. V1 then carries channel_mask, frame_count, overflow_sat, crc_alg, and 16-bit channel status. V2 starts 8-bit per-channel status at offset 12; the removed fields are derived from the Active Profile or SDO diagnostics.

5.1 Version selection, byte layout, and compatibility boundary

ver_ihl is the final runtime authority: its high nibble is the header version and its low nibble is the number of 4B words. OptionFlags requests a version; ver_ihl confirms the version and length actually used by the current PDO image. Firmware 2.x indicates V2 capability, not a V2 default.

Common first 12 bytes
offset  0       1       2..3      4..5      6..7        8..9       10..11
       +-------+-------+----------+----------+------------+-----------+----------+
       |ver_ihl| flags |seq_begin | seq_end  |payload_len |payload_crc| layout_id|
       +-------+-------+----------+----------+------------+-----------+----------+

HPM5E / 4 channels
V1  +12: channel_mask/frame_count/overflow_sat/crc_alg +16: status[4]x2B -> payload@24
V2  +12: status[4]x1B                                           -> payload@16

HPM6E / 8 channels
V1  +12: channel_mask/frame_count/overflow_sat/crc_alg +16: status[8]x2B -> payload@32
V2  +12: status[8]x1B                                           -> payload@20

!!! danger "Never infer the header from firmware or PDO size" Firmware 2.x advertises V2 capability; it does not mean the current image uses V2. :03 selects total length, :07 bit5 requests the version, and active readback confirms the configuration. The actual image format and length must come from ver_ihl.

The fixed header is not an SDO object and does not have the RO/RW attribute; its master access direction follows the PDO direction: the RxPDO header is written by the master and parsed by the slave, and the TxPDO header is written by the slave and parsed by the master.

Common fields in both versions:

V1 carries channel_mask, frame_count, overflow_sat, and crc_alg at offsets 12..15, followed by 16-bit status per channel. V2 omits those four bytes and starts 8-bit status per channel at offset 12. In V2 the channel mask and CRC policy come from the applied Active Profile, frame count is derived while traversing the stream, and overflow is reported by header_flags.bit5.

Publishing rules: The sender first constructs the complete frame area and header, then writes seq_end = seq_begin last. The receiver parses only when the sequence and length are valid and the CRC field matches the applied direction option. Factory-default V1+NO_CRC16 requires payload_crc16=0; clearing NO_CRC16 enables CRC-16/CCITT-FALSE without changing the selected header version or length. This prevents either side from consuming a half-updated PDO.

5.2 Key field explanation and reception judgment

seq_begin, seq_end, and layout_id are common running fields rather than separately configured SDO parameters. V1 additionally carries crc_alg and overflow_sat; V2 derives the CRC mode from Active Profile and replaces overflow count with the header overflow flag.

Notes:

• layout_id is a short identifier in the PDO header. It lets the master quickly detect whether the current PDO layout has changed. For full configuration readback, read 0x8010/0x8011:12 Active profile word and :11 Active layout CRC.
• If overflow_set appears in the document or debugger, it corresponds to this header field overflow_sat: it is not a switch, but "the saturation count after overflow/truncation in this cycle."
• When enabled, payload_crc16 covers PDO offset [HeaderBytes, HeaderBytes + payload_len) and never includes the versioned header. The factory default disables this CRC and requires the field to be 0.
• payload_len is the actual number of valid frame encapsulation bytes in this cycle, not the total length of PDO.

!!! caution "Clear unused space and alignment padding" Unused frame-area bytes shall be zero. With ALIGN_4_ENABLE, padding bytes shall also be zero and shall be included in payload_len; the receiver shall advance by the aligned packet length.

Recommended judgment sequence for the receiving end:

1. Read fixed header A.
2. Check seq_begin == seq_end; if not equal, ignore the PDO of this cycle.
3. Derive the CRC policy from the applied profile.
   Under factory-default NO_CRC16, require payload_crc16 == 0.
   With CRC enabled, V1 also reports crc_alg == 1; V2 omits that field.
4. Check payload_len <= ActiveFrameAreaBytes.
5. When enabled, calculate CRC-16/CCITT-FALSE for payload_len bytes
   starting at HeaderBytes.
6. Read fixed header B again. If the key fields of A and B differ,
   the PDO changed during the read; ignore this cycle.
7. Parse CAN_FRAME packets; reject all reserved packet kinds.
8. If overflow_sat != 0 or STREAM_TRUNCATED=1, mark this cycle as incomplete data.

Configuration example: When the master wants both TxPDO/RxPDO to use the default N=2, CAN0..CAN3, profile 0, Balanced, V2 header and no payload CRC:

0x1C12 / 0x1C13: Select the first 2 128B chunks
0x8010:03 = 2     TxPDO PDO size multiplier
0x8010:04 = 0x0F  TxPDO channel mask
0x8010:05 = 0     TxPDO profile 0
0x8010:06 = 0     TxPDO Balanced budget
0x8010:07 = 0x24  TxPDO option flags: HEADER_V2 + NO_CRC16
0x8010:01 = 1     apply TxPDO profile

0x8011:03 = 2     RxPDO PDO size multiplier
0x8011:04 = 0x0F  RxPDO channel mask
0x8011:05 = 0     RxPDO profile 0
0x8011:06 = 0     RxPDO Balanced budget
0x8011:07 = 0x24  RxPDO option flags: HEADER_V2 + NO_CRC16
0x8011:01 = 1     apply RxPDO profile

Read 0x8010/0x8011:09..12 after apply. If Active PDO bytes, Active frame area bytes, Active layout CRC, Active profile word are as expected, layout_id in subsequent PDO headers should remain stable.

header_flags：

6. Channel status word

Each channel status is compressed to 16 bits and placed in the PDO header. PDO only carries fast status, detailed reasons are read through SDO.

When warn/bus_off/rx_pressure/tx_pressure/detail_pending is set, the master should read 0x9000..0x9003 to obtain a detailed register and count snapshot. If the error comes from the PDO encapsulation layer, LastPDOError / PDOErrorCounter / PDOOverflowCounter of 0x8010/0x8011 should be read.

7. Frame encapsulation package

Each frame encapsulation packet starts with a 2B control word, which determines the length of subsequent CAN ID, timestamp and data.

The frame encapsulation packet follows the PDO direction: CAN_FRAME in RxPDO is the master's request for the slave to send to the CAN bus; CAN_FRAME in TxPDO is received by the slave from the CAN bus and uploaded to the master.

Unless otherwise specified, multi-byte values in PDO fixed headers, frame packets and SDO use little-endian. On the master side, do not cast unaligned byte buffers directly to host structures. Read and write fields explicitly from the byte stream.

Byte0:
  bit0..2 CH CAN channel id, currently using 0..3
  bit3..6 DLC original CAN DLC, 0..15
  bit7     IDE      0=11bit standard id，1=29bit extended id

Byte1:
  bit0     FDF      0=classic CAN，1=CAN FD
  bit1     BRS      CAN FD bit rate switch
  bit2 X When FDF=0, it is RTR, when FDF=1, it is ESI
  bit3..4  TSF      0=no timestamp，1=delta16，2=delta32，3=full64
  bit5..6  KIND     0=CAN_FRAME, 1..3=reserved
  bit7     D64      0=data length by DLC，1=fixed 64B data window

The current protocol only accepts KIND=0 CAN_FRAME. KIND=1..3 are reserved and must be rejected by the receiver.

7.1 CAN_FRAME format

Standard ID:
  Ctrl[2] + StdIdField[2] + Timestamp[0/2/4/8] + Data[0..64] + Padding

Extended ID:
  Ctrl[2] + ExtIdField[4] + Timestamp[0/2/4/8] + Data[0..64] + Padding

StdIdField:

ExtIdField：

ID_AUX suggested semantics:

When not used, the sender must write 0 and the receiver ignores it.

7.2 DLC and data length

DLC<=8, BRS=0, D64=0 in classic CAN. If FDF=0 && X=1, the frame is RTR, and the data length must be 0. X in CAN FD represents ESI, and there is no RTR.

7.3 Packet length calculation

id_bytes = IDE ? 4 : 2
ts_bytes = TSF == 0 ? 0 : (TSF == 1 ? 2 : (TSF == 2 ? 4 : 8))
data_bytes = (FDF == 0 && X == 1) ? 0 :
             (D64 ? 64 : can_dlc_to_len(DLC))
raw_packet_bytes = 2 + id_bytes + ts_bytes + data_bytes
packet_bytes = ALIGN_4_ENABLE ? align4(raw_packet_bytes) : raw_packet_bytes

!!! caution "Capacity is checked at complete-packet boundaries" The unused frame area must be filled with 0. If 4-byte alignment is enabled, padding bytes must be 0 and counted in payload_len. If the remaining area cannot contain a complete packet, the sender shall not write a partial packet.

7.3.1 Enable 4-byte alignment

4-byte alignment is controlled by the direction option ALIGN_4_ENABLE, not the 0xF000 read-only capability object that is turned on directly. 0xF000:15 (0x0F) is used to confirm whether the device claims to support this capability; the real switch is 0x8010/0x8011:07 (0x07) Option flags bit1.

Turn on steps:

1. Read 0xF000:15 and confirm that bit1 ALIGN4 option mask is 1.
   You can also read 0xF000:16 and confirm that bit5 ALIGN4 feature is 1.
2. Write 0x8010/0x8011 requested profile in PREOP/SAFEOP.
3. Set 0x8010:07 or 0x8011:07 bit1 of the target direction to 1.
4. Write 0x8010:01 = 1 or 0x8011:01 = 1 apply.
5. Read 0x8010/0x8011:02 and confirm Status = 0.
6. Read 0x8010/0x8011:12 and confirm that OptionFlags bit1
   is set in the Active profile word.

Example: Leave other direction options unchanged and only turn on RxPDO 4-byte alignment:

old = read_u8(0x8011:07)
write_u8(0x8011:07, old | 0x02)
write_u8(0x8011:01, 1)
check read_u8(0x8011:02) == 0

Example: Turn off TxPDO 4-byte alignment:

old = read_u8(0x8010:07)
write_u8(0x8010:07, old & ~0x02)
write_u8(0x8010:01, 1)
check read_u8(0x8010:02) == 0

After ALIGN4 is enabled, the sender must pad each frame packet to a 4-byte boundary. Padding bytes must be 0 and must be included in the fixed header payload_len. The receiver must also advance by the aligned packet_bytes when parsing the next packet, not by the raw CAN data length alone.

Length example:

7.4 Timestamp field

TSF determines whether CAN_FRAME carries the timestamp field. In the ordinary TxPDO upload direction, the timestamp is used to describe the time when the slave receives the CAN frame; in the RxPDO delivery direction, TSF_NONE means immediate transmission, and TSF_FULL64 can be multiplexed by the reserved transmission format.

delta16/delta32 within the same Packet sequence in TxPDO is referenced to the first available time base of the cycle. The master should handle wrap as an unsigned difference when used for sorting and diagnostics. If the master does not need timestamps, it is recommended to use profile 0/4 to reduce the overhead of each frame.

RxPDO reservation sending only uses the 8B field of TSF_FULL64, and the required format is as follows:

format:u8 = 1
flags:u8 = 0
tag:u16
offset_ns:u32

offset_ns represents the target phase relative to the starting point of the next SYNC0 cycle. This format is not an absolute timestamp; if the target phase has been missed, the firmware will not delay the frame until the next cycle and the master should reserve sufficient phase margin.

8. Encapsulation Profile and direction options

0x8010 controls the TxPDO profile, and 0x8011 controls the RxPDO profile. Currently, the following profiles are supported out of the factory:

Direction options are controlled by 0x8010/0x8011:07 Option flags. 0x8010 acts in the TxPDO/SM3/Input upload direction, and 0x8011 acts in the RxPDO/SM2/Output delivery direction.

8.1 Option flags bit table

Option flags is an 8-bit bitmap. Writing the requested value does not make it active.

!!! caution "Apply and read back" After writing options, issue 0x8010:01=1 or 0x8011:01=1. Use the new layout only when :02=0 and :12 Active profile word matches the request. Reserved bits must remain 0; use read-modify-write for a single-option change.

Commonly written values:

Ability judgment:

The current capability mask is based on 0xF000. The master should read the capability object first and then select the profile and option flags.

!!! important "Default CRC policy" Payload CRC16 is disabled by default for both V1 and V2. When disabled, TxPDO payload_crc16 shall be zero and the firmware skips the field in master RxPDO input. To enable CRC protection, the master shall explicitly clear NO_CRC16_ENABLE.

8.2 Default switch state when not configured

If the master does not write the profile-related SDO of 0x8010/0x8011, the default value of requested in the device object dictionary is as follows. Note: 0xF000 means "support capability" and does not mean enabled by default; the actual enabled status is determined by the requested profile of 0x8010/0x8011 and the active readback after apply.

It is recommended that masters not rely on the assumption that implicit defaults are in effect. When starting up, you should explicitly configure 0x1C12/0x1C13, write 0x8010/0x8011:03..07, then write 0x8010/0x8011:01=1 apply, and read :09..12 to confirm the active status.

9. Reserved protocol values

OptionFlags.bit0, header_flags.bit2, and packet KIND=1..3 are reserved. A master must transmit zero in reserved option and header bits and must reject reserved packet kinds. Firmware does not provide per-frame transmit-result packets. Confirm end-to-end completion through the CAN peer response; use PDO channel status and SDO diagnostics for local congestion and bus-state diagnosis.

10. CRC and integrity strategy

By default, CRC32 is not added to each CAN_FRAME.

Reason:

• The CAN/CAN FD bus itself already has CAN CRC.
• EtherCAT frame has link FCS and working counter.
• per-frame CRC32 will increase 4B/frame, and the classic 8B standard frame overhead increases from 12B to 16B, about 33%.
• Frame-by-frame CRC32 adds jitter to the packet calculation in 1ms periods.

By default, ActiveLayoutCrc, double sequence commit and length checks protect the layout and update boundary, while payload CRC16 is disabled for the hot path. Clear OptionFlags.bit2 to enable CRC-16/CCITT-FALSE without changing the selected header version or length.

11. Multi-channel shared budget

PDO no longer provides fixed slots for each CAN channel. The scheduler works on a frame area byte budget:

frame_area = ActivePDOBytes - HeaderBytes
reserved_bytes = enabled_channel_count * policy_reserved_bytes
shared_bytes = frame_area - reserved_bytes

Budget strategy:

A CAN_FRAME must be put into the frame area of this cycle as a whole, and splitting across cycles is not allowed. If there is insufficient space, set the device to STREAM_TRUNCATED, add overflow_sat and SDO PDOOverflowCounter.

12. SDO object dictionary

The previous chapters describe periodic PDO data, which is exchanged every EtherCAT cycle after OP. The SDO object dictionary is the configuration and diagnostics entry point: use it before OP to configure PDO profiles and MCAN channels, and use it during operation to read capabilities, error counters, and detailed status. If you only need to look up an object, start from this chapter. For bring-up, read 13.1, 13.2, 13.4, and 13.8 first.

This chapter lists only the public objects intended for customer integration. Objects not listed here are manufacturer-reserved, carry no compatibility commitment, and must not be accessed by customer applications. U8/U16/U32 denote unsigned 8/16/32-bit values.

12.1 Quick lookup by object index

In a PDF reader, start with the Bookmarks or Contents pane. If the address is known, search the complete hexadecimal token, such as 0x8010:07 or 0xF000:16. If only the function is known, search the English keywords below. Ranged objects also list each member address so a search for 0x8002 or 0x9023 lands directly in this index.

Frequently searched subindices:

12.1.1 Object overview

12.2 0x8010/0x8011 PDO Profile Control

0x8010 controls the TxPDO/Input direction, and the data flow is S2M; 0x8011 controls the RxPDO/Output direction, and the data flow is M2S. SI1/3/4/5/6/7/8 is the requested configuration or command written by the master, and SI2/9..16 is the status and active readback returned by the slave.

Status Common values:

Active profile word packaging format:

Command bit definition:

Last PDO error common values:

PDO error counter counts encapsulation layer errors such as parsing, CRC, and illegal fields; PDO overflow counter counts overflow or discarding caused by insufficient frame area in this cycle and TX/RX back pressure. During on-site inspection, first check Status, and then check LastPDOError and whether the two counters continue to increase.

12.2.1 0x8021..0x8024 MCAN Data Path Control

0x8021..0x8024 correspond to MCAN0..MCAN3. Normal applications should keep the firmware defaults. Override these values only when measurements under real CAN/CAN FD load show that the per-service budget is insufficient. These objects do not change bit timing, filters, or Message RAM configuration.

The stable customer-facing subindices are listed below. Other subindices in these objects are advanced policies or reserved extensions and are not part of the customer interface contract.

The following IgH MCAN Port API calls use these indices:

After either budget setter is called, igh_mcan_port_apply_config() also writes SI1=1 for that channel and finally writes SI2=1. The default configuration does not write 0x8021..0x8024, preserving old-firmware compatibility and the factory policy. Raising a budget can increase instantaneous CAN bursts and CPU service load; always repeat loss-counter and latency-tail tests with real traffic.

12.2.2 Data-path budget configuration sequence

For manual configuration, use this order:

1. Confirm that the target firmware provides the object. If old firmware reports “object does not exist,” retain its default policy instead of failing the entire startup.
2. Write SI1=1.
3. Write only the required SI5 and/or SI12 override, in the range 0..8.
4. Write SI2=1 to apply.
5. Read SI3 and SI20 to confirm success and the active value.

12.2.3 Manufacturer test and maintenance objects

Data-path bypass tests, direct-register access, persistent maintenance, and manufacturing objects are reserved for manufacturer support. Customer applications must not depend on or write them. For advanced troubleshooting, read 0x9011, 0x9020..0x9023, the standard status and error counters, and export the runtime log.

12.2.4 0x9011 Cycle Performance Diagnostics

0x9011 exposes interrupt counts, PDI/DC phase, and worst-case firmware critical-path timing. All fields below are read-only except Clear command. Timing values are CPU cycles and can be converted using the CPU clock returned by 0x8000:04. A field may remain zero when its corresponding measurement is not enabled in the firmware build.

Unlisted subindices are compatibility or manufacturer diagnostic extensions. Customer software must not interpret their bit layouts.

12.2.5 0x9020..0x9023 MCAN Data Path Diagnostics

0x9020..0x9023 correspond to MCAN0..MCAN3. They distinguish CAN receive backlog, insufficient PDO capacity, MCAN TX backpressure, bus-off, and an insufficient channel service budget.

If RX cache high watermark stays near the cache limit while RX dropped total rises, CAN input or PDO packing is exceeding the configured capacity. A rising TX FIFO full count instead indicates insufficient CAN transmit capacity or a non-responsive downstream node. Interpret both together with the 0x8010/0x8011 overflow counters and the master's WKC.

12.3 0x8000 System Config

CAN pin rotation only allows rotation of logical channels between fixed sets of CAN pins at the chip/board level and does not provide arbitrary GPIO muxing configurations.

12.4 0x8001..0x8004 MCAN Channel Config

Each channel has the same structure. 0x8001 corresponds to CAN0, and 0x8004 corresponds to CAN3.

The subindices are grouped by function below. Most applications only need to configure SI15/16/19/20 and the required FIFO/Queue parameters; filters, TSU, and timeout settings are advanced options.

Channel commands and status:

Node mode value:

Manual bit timing only takes effect at SI7 Bit timing mode = 1. In automatic mode, the master configures Nominal/Data bitrate and the sample point range, and the firmware solves BRP/TSEG/SJW according to the MCAN source clock. The sample point range should follow the peer device configuration: when the peer sample point is known, set both min and max to the target sample point; otherwise start from the peer documentation recommendation and verify frame exchange quality. In manual mode, SI25..32 is used.

Filter global fields:

Filter editing window:

Entry cmd：

Entry status：

Typical filter configuration process:

1. Read Std list max / Ext list max to confirm the capacity.
2. Write Std filter count or Ext filter count.
3. Write current index.
4. Write filter type/action/sync/id1/id2.
5. Write entry cmd = 2 to save the current index.
6. Repeat to configure multiple entries.
7. Write Apply command = 1 to make the channel configuration take effect.
8. If you need to save when power off, write Flash command bit0 = 1.

RAM/FIFO/Buffer fields:

Note: the SI column below is decimal. Many master tools display subindices in hexadecimal. The commonly mentioned 0x41/0x42/0x44 are decimal 65/66/68, corresponding to the RX FIFO0, RX FIFO1, and RX Buffer element data sizes. These fields only define the maximum data bytes stored in one MCAN Message RAM element. They do not define the CAN FD DLC inside a PDO packet; the actual DLC is still carried by the frame packet in RxPDO/TxPDO.

data size uses the HPM MCAN driver enumeration and is not the byte value itself. Common values are:

The Message RAM budget is determined by both element counts and data size. The general CAN FD default is RXFIFO0=48, RXFIFO1=12, RXBUF=12, TXFIFO=32, TXBUF=0, TXEVENT=32, data size=7. Classic CAN may reduce data size to 0 to save RAM for more elements. If the configuration is illegal or exceeds the per-channel Message RAM budget, Apply status reports an error and the runtime channel does not switch to the new layout.

Timestamp/TSU/Timeout fields:

TDC Strategy:

• CAN FD default TDC enable=1.
• When the data segment is less than 5M, the master can turn off TDC through SDO.
• When the data segment reaches 5M or more, the firmware ignores TDC enable=0 and forcibly turns on TDC.
• TDC offset/filter defaults to 0, which means it is automatically calculated by the HPM MCAN driver according to the actual data segment timing.
• TDC offset/filter that is not 0 is still retained by the firmware and distributed to the MCAN driver for debugging by on-site experts.
• It is recommended to configure offset/filter in pairs when manually overwriting.

12.5 0x9000..0x9003 MCAN Channel Information

These objects are RO and use the S2M direction. The master reads them when it needs detailed channel status beyond the compact PDO header state.

12.6 Manufacturer maintenance interfaces

!!! danger "Non-public interfaces" Register access, factory maintenance, and persistent-storage repair are not public product APIs. Never modify controller registers or device storage through SDO at a customer site. Use the official service process for recovery or advanced diagnosis.

12.7 0xF000 Device Objects

The master must read the 0xF000 capability object before selecting the PDO profile.

The object is RO and the direction is S2M. It is used by the master to identify the device capabilities, version and protocol upper limit.

PDO capabilities and upper limits:

Encapsulation profile mask：

PDO option flags mask：

PDO feature flags：

Device service flags：

RxPDO reserves the TSF_FULL64 field of the multiplexed dynamic frame and does not change the ordinary CAN frame packet structure:

format:u8 = 1
flags:u8 = 0
tag:u16
offset_ns:u32

TSF_NONE is still sent immediately; TSF_FULL64 format=1 means offset_ns phase sending is reserved for the next SYNC0 cycle. The same phase is queued in PDO frame order.

Reservation delivery implementation constraints:

• The master must first confirm that bit 8 (mask 0x00000100) is set in 0xF000:16, indicating RxPDO TSF scheduled-transmit support.
• offset_ns takes the current EtherCAT DC/SYNC0 cycle as a reference. It is recommended to use 100000ns or a larger conservative phase for bring-up first.
• The device schedules reserved frames according to the SYNC0 phase; frames that have exceeded the target phase will not be retransmitted across cycles, and the master should reserve sufficient offset_ns margin.
• Scheduled sending and direct sending share the CAN sending path; when the channel is congested or sending is abnormal, feedback is provided through PDO status and SDO diagnostic count.
• When the master is stopped, the ESC process data area may keep the last frame of RxPDO image; the firmware treats the exact same repeated image as idempotent no-op and does not record it as a real parsing error.

12.8 Comparison of real-time performance between scheduled delivery and direct delivery

Scheduled sending cannot compensate for an unstable master cycle. Before enabling it, verify a stable EtherCAT cycle, DC state, and WKC, then validate the transmit phase with a CAN analyzer under the actual cabling and load.

13. Technical specifications

14. Revision history