ECAN-Lite 技术参考手册 V3.0
本手册完整定义产品架构、EtherCAT/CAN FD协议、PDO字节布局、封装格式、对象字典、默认值和诊断接口。
接线、主站配置、IgH示例、FoE升级、运行调试和验收步骤见
《ECAN-Lite 应用手册 V3.0》 。
章节目录
[TOC]
1. 产品定位
ECAN-Lite 是 EtherCAT 到 CAN/CAN FD 的实时网关从站。主站通过 RxPDO 下发发送请求，通过 TxPDO 读取接收帧、发送结果和通道状态。
周期数据采用固定头部与连续帧流两层结构：
text Copy VersionedFixedPdoFrameHeader + FramePacketStream[ActivePDOBytes - HeaderBytes]固定头通过 ver_ihl 自描述格式和长度；后续帧区连续存放 CAN/CAN FD 封装包。PDO大小、头部版本和能力差异分别在第4章和第5章定义。
!!! important "规范性说明"
本手册中的“必须”表示协议约束，“建议”表示推荐实现，“可以”表示可选能力。对象字典、位定义、默认值和边界条件以本手册为准；操作步骤以应用手册为准。
2. 核心特性
3. 方向定义与系统架构
TxPDO 与 RxPDO 是独立方向，可分别选择 PDO 大小、通道掩码、封装 profile、预算策略和方向选项。
通道使能与 PDO 大小互不替代。关闭 CAN 通道只改变 active channel mask 和调度预算，不改变 SM2/SM3 长度。
理解本文时可以把协议分成三层：
首次收发按应用手册第1章执行。自行实现 PDO codec 时，必须阅读本手册第4至11章。
!!! warning "方向混淆会造成静默错误"
RxPDO/SM2 是主站写、从站读；TxPDO/SM3 是从站写、主站读。注册过程映像、命名 buffer 和调用收发 API 时必须始终保持这一方向定义。
3.1 文档标记说明
本文后续表格使用以下标记：
PDO 表格中的 访问 指主站对过程数据的访问方式：RxPDO/SM2 为主站写，从站读；TxPDO/SM3 为从站写，主站读。SDO 表格中的 访问 指主站通过 CoE 对对象字典子项的访问属性。
3.2 系统架构
text Copy 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 CAN34. EtherCAT PDO映射与大小
4.1 128B Chunk 映射
PDO 映射按 128B chunk 拼接。每个 chunk 在对象字典中拆成 8 个 STRING(16) 映射单元，以避免 PDO mapping entry 的 bit length 限制。
text Copy RxPDO chunk maps: 0x1600..0x1617
TxPDO chunk maps: 0x1A00..0x1A17
SM2 assignment: 0x1C12 选择前 N 个 RxPDO chunk
SM3 assignment: 0x1C13 选择前 N 个 TxPDO chunkchunk 是 EtherCAT 映射和长度选择单位，不是协议解析层。基础区域由完整 128B chunk 组成；有 16B 微调时，再追加一个尾 mapping，并只启用该 mapping 的前 fine 个 16B entry。FramePacketStream 可以跨边界，接收端只按固定头部中的 payload_len 解析有效帧区。
!!! danger "PDO assignment 与长度必须一致"
0x1C12/0x1C13 的有效 mapping 字节数必须等于对应方向的 ActivePDOBytes。两者不一致时设备会拒绝 profile，主站也可能无法进入 OP。禁止在 OP 状态在线改变 PDO 长度。
4.1.1 多个 chunk 在主站侧如何拼接
主站侧不要把 0x1600..0x1617 / 0x1A00..0x1A17 当成多段独立协议解析。它们只是为了适配 EtherCAT PDO mapping 限制而拆出的 128B 映射块。应用层应把同一方向的前 N 个 chunk 按 assignment 顺序拼成一个连续 byte buffer：
text Copy RxPDO/SM2 output buffer:
chunk0[128B] + chunk1[128B] + ... + chunkN-1[128B]
其中 ... 表示省略中间连续 chunk，顺序和大小均按 128B 递推
TxPDO/SM3 input buffer:
chunk0[128B] + chunk1[128B] + ... + chunkN-1[128B]
其中 ... 表示省略中间连续 chunk，顺序和大小均按 128B 递推每个 128B chunk 又由 8 个 STRING(16) 映射单元组成。主站如果把它们暴露成多个变量，应用需要按以下顺序复制：
text Copy for chunk = 0 .. N-1:
for unit = 0 .. 7:
dst_offset = chunk * 128 + unit * 16
copy 16 bytes to/from process image entry下面表格完整展开 chunk=0 的 8 个映射单元，并用省略行表示后续 chunk 按相同规律递推。完整关系以随后公式为准。
完整映射规律：
通用公式：
text Copy unit_index = chunk * 8 + unit
offset = unit_index * 16
RxPDO 数据对象 index = 0x7000 + unit_index * 0x10
TxPDO 数据对象 index = 0x6000 + unit_index * 0x10因此 chunk=1 时并不只有 unit=0。例如 RxPDO 0x1601 实际包含 0x7080, 0x7090, ..., 0x70F0 八个 16B 单元，其中 ... 表示省略中间按 0x10 递增的对象；TxPDO 0x1A01 实际包含 0x6080, 0x6090, ..., 0x60F0 八个 16B 单元，其中 ... 同样表示省略中间按 0x10 递增的对象。
例如 N=3 时，每个方向的连续 buffer 为 384B：
text Copy chunk0: offset 0..127
chunk1: offset 128..255
chunk2: offset 256..383固定头位于连续buffer的offset0；帧区从HeaderBytes=4*(ver_ihl&0x0F)开始。默认V1在5E/6E分别为24B/32B；显式启用V2后分别为16B/20B。
在 TwinCAT、CODESYS 或自研主站中，如果工具支持将 PDO 映射直接映射为连续 Byte Array，推荐直接建立 ARRAY[0..ActivePDOBytes-1] OF BYTE。如果工具只能把每个 STRING(16) 暴露为单独变量，则按上面的 offset 公式在应用层拼接和拆分。
4.2 PDO总长度与头部开销的关系
PDO总长度和固定头版本是两个独立配置维度，但二者共同决定可用于CAN帧的空间：
text Copy SIZE（0x8010/0x8011:03） ──> ActivePDOBytes（PDO总长度）
VERSION（0x8010/0x8011:07 bit5） ──> HeaderBytes（头部长度）
ActivePDOBytes - HeaderBytes ──> ActiveFrameAreaBytes（可用帧区）
ASSIGN（0x1C12/0x1C13） == ActivePDOBytes
IHL（ver_ihl.IHL） ──> 运行期实际 HeaderBytes!!! important "长度与头部版本是两个配置维度"
切换头部版本不改变 SM2/SM3 长度，也不要求重建 PDO assignment；它只改变帧区起点和可用字节数。改变 PDO 总长度不切换头部版本，但主站必须同步修改 EtherCAT mapping。
4.2.1 大小字段：兼容5+3编码
text Copy base = PdoSizeEncoding & 0x1F
fine = PdoSizeEncoding >> 5
ActivePDOBytes = 128 * base + 16 * fine
ECAN-Lite: base=1..10, fine=0..7设备对象0x8010/0x8011:03的请求值出厂默认均为0x02，即256B。低5bit选择完整128B基础块；高3bit在能力允许时追加0..7个16B尾单元。旧主站写1..10时高位始终为0，仍保持原来的128B步进。
仅当0xF000:16 bit7 FINE_SIZE_16=1时才使用fine。fine>0时，0x1C12/0x1C13除前base个完整chunk外还要追加尾mapping，并只启用其前fine个16B entry。该能力位只是只读声明，不是配置开关。
4.2.2 同一PDO总长度下的实际帧区
下表把“总长度”和“协议开销”分开列出。帧区数值均按ActivePDOBytes-HeaderBytes计算：
V2节省的空间来自固定头压缩：5E每个PDO image增加8B帧区，6E增加12B帧区。这个增量不改变EtherCAT线上的PDO总字节数。V2减少的字段和状态精度见第5章；不能只为了增加几字节容量而切换版本，必须同时确认主站codec支持。
4.2.3 配置变化对主站的影响
4.2.4 能力确认与active回读
配置前后应检查以下对象，不能只相信requested SDO写入成功：
推荐配置顺序：
读取能力对象；
选择总长度并建立 mapping；
选择头部版本并 apply；
回读 :02 和 :09..12；
进入 OP 后仍按每个 image 的 ver_ihl 计算 HeaderBytes。
!!! caution "容量不等于实时性能"
大 PDO 只增加过程映像空间，也增加 EtherCAT 帧长度和 PDI 搬运量。必须在目标周期、从站数量和 CAN 负载下验证 WKC、周期抖动与丢帧计数。
4.3 ESI 与 PDO 映射要求
请使用随产品发布的 ESI 文件创建从站配置，不要自行修改设备 SII/EEPROM。
主站实际使用的 PDO 长度由 0x1C12/0x1C13 assignment 选择连续的基础 chunk 和可选尾 mapping
决定，并必须与 0x8010/0x8011 的 active profile 保持一致。若 ESI、设备
固件或主站配置版本不匹配，请恢复为对应发布包并联系技术支持。
5. PDO 固定头部
TxPDO和RxPDO使用相同版本规则。ver_ihl高4bit为版本、低4bit为4B word数。OptionFlags.bit5=HEADER_V2选择V2；清零选择V1。出厂、复位和新版IgH默认OptionFlags=0x04，即V1并关闭payload CRC16；V2必须由主站显式置bit5。
5.1 版本选择、字节布局与兼容边界
ver_ihl是运行期数据面的最终依据：高4bit是头部版本，低4bit是头部4B word数。OptionFlags用于请求版本，ver_ihl用于确认当前PDO image实际采用的版本和长度。固件版本为2.x只表示具备V2能力，不表示默认发送V2。
text Copy 共同的前12B
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通道
V1 +12: channel_mask/frame_count/overflow_sat/crc_alg +16: status[4]×2B -> payload@24
V2 +12: status[4]×1B -> payload@16
HPM6E / 8通道
V1 +12: channel_mask/frame_count/overflow_sat/crc_alg +16: status[8]×2B -> payload@32
V2 +12: status[8]×1B -> payload@20!!! danger "禁止按固件版本或 PDO 大小猜测头部"
固件 2.x 只表示具备 V2 能力，不表示当前 image 使用 V2。:03确定总长度，:07 bit5请求版本，active readback确认配置；每个 image 的实际版本和头长必须由 ver_ihl 判断。
固定头部不是 SDO 对象，没有 RO/RW 属性；它的主站访问方向跟随 PDO 方向：RxPDO 头部由主站写入并由从站解析，TxPDO 头部由从站写入并由主站解析。
V1在offset12携带channel_mask/frame_count/overflow_sat/crc_alg，通道状态从offset16开始。V2删除这4个字段：通道掩码和CRC模式从Active Profile推导，帧数遍历帧流得到，溢出使用header_flags.bit5表示；通道状态从offset12开始，每路1B。HPM5E/HPM6E分别占16B/20B。
发布规则：发送端先构建完整帧区和头字段，最后写seq_end=seq_begin。默认V1+NO_CRC16要求payload_crc16=0；清除NO_CRC16后仍使用CRC-16/CCITT-FALSE。CRC关闭不会取消双序号、长度和layout检查。
5.2 关键字段解释与接收判断
seq_begin、seq_end、layout_id是两版共有字段。V1的crc_alg/overflow_sat在V2中分别由Active Profile和header_flags.bit5替代。
说明：
layout_id 是 PDO 头部中的短标识，便于主站快速判断“当前 PDO 布局是否变过”。完整配置回显应读取 0x8010/0x8011:12 Active profile word 和 :11 Active layout CRC。文档或调试口径中如果出现 overflow_set，对应的是本头部字段 overflow_sat：它不是一个开关，而是“本周期发生溢出/截断后的饱和计数”。
payload_crc16的计算范围从header_bytes=ihl*4开始，即[header_bytes, header_bytes+payload_len)。payload_len 是本周期实际有效帧封装字节数，不是 PDO 总长度。
!!! caution "未使用区和对齐填充必须清零"
未使用帧区必须填 0。启用 ALIGN_4_ENABLE 时，padding 字节也必须写 0，并计入 payload_len；接收端必须按对齐后的包长前进。
接收端推荐判断顺序：
text Copy 1. 读取固定头部 A。
2. 检查 seq_begin == seq_end；不相等则忽略本周期 PDO。
3. 根据Active Profile判断CRC；默认NO_CRC16检查`payload_crc16==0`。
4. 检查 payload_len <= ActiveFrameAreaBytes。
5. CRC开启时对offset `ihl*4`开始的payload_len字节计算CRC-16/CCITT-FALSE。
6. 再读取固定头部 B；若 A 与 B 关键字段不一致，说明读期间 PDO 被更新，忽略本周期。
7. 解析 CAN_FRAME；其他 KIND 必须拒绝。
8. V1检查`overflow_sat`，V2检查`OVERFLOW_OCCURRED`；任一版本出现`STREAM_TRUNCATED`均标记不完整。配置示例：主站希望TxPDO/RxPDO都使用默认N=2、CAN0..CAN3、profile 0、Balanced、V2头且关闭payload CRC时：
text Copy 0x1C12 / 0x1C13: 选择前 2 个 128B chunk
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 profileapply 后读取 0x8010/0x8011:09..12。如果 Active PDO bytes、Active frame area bytes、Active layout CRC、Active profile word 与预期一致，后续 PDO 头部中的 layout_id 应保持稳定。
header_flags：
6. 通道状态字
每路通道状态压缩为 16bit，固定放在 PDO 头部。PDO 只承载快速状态，详细原因通过 SDO 读取。
当 warn/bus_off/rx_pressure/tx_pressure/detail_pending 置位时，主站应读取 0x9000..0x9003 获取详细寄存器和计数快照。若错误来自 PDO 封装层，应读取 0x8010/0x8011 的 LastPDOError / PDOErrorCounter / PDOOverflowCounter。
7. 帧封装包
每个帧封装包从 2B 控制字开始，控制字决定后续 CAN ID、时间戳和 data 的长度。
帧封装包跟随 PDO 方向：RxPDO 中的 CAN_FRAME 是主站请求从站发送到 CAN 总线；TxPDO 中的 CAN_FRAME 是从站从 CAN 总线收到后上传给主站。
除特别说明外，PDO 固定头部、CAN_FRAME 和 SDO 中的多字节数值均使用 little-endian。主站侧不要按主机字节序直接强转未对齐结构体，建议按字节流显式读取。
text Copy Byte0:
bit0..2 CH CAN channel id，当前使用 0..3
bit3..6 DLC 原始 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 FDF=0 时为 RTR，FDF=1 时为 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当前固件只支持 KIND=0 CAN_FRAME。KIND=1..3 均为保留值，主站不得生成，收到时必须视为非法。
7.1 CAN_FRAME 格式
text Copy 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] + PaddingStdIdField：
ExtIdField：
ID_AUX 建议语义：
未使用时发送端必须写 0，接收端忽略。
7.2 DLC 与数据长度
classic CAN 中 DLC<=8、BRS=0、D64=0。若 FDF=0 && X=1，该帧为 RTR，data length 必须为 0。CAN FD 中 X 表示 ESI，不存在 RTR。
7.3 包长度计算
text Copy 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 "完整包边界是容量判断单位"
未使用帧区必须填 0。若开启 4 字节对齐，padding 字节必须为 0 并计入 payload_len。剩余空间不足以容纳完整包时，不得写入半包。
7.3.1 开启 4 字节对齐
4 字节对齐由方向选项 ALIGN_4_ENABLE 控制，不是 0xF000 只读能力对象直接开启。0xF000:15 (0x0F) 用于确认设备是否声明支持该能力；真正的开关在 0x8010/0x8011:07 (0x07) Option flags bit1。
开启步骤：
text Copy 1. 读取 0xF000:15，确认 bit1 ALIGN4 option mask 为 1。
也可读取 0xF000:16，确认 bit5 ALIGN4 feature 为 1。
2. 在 PREOP/SAFEOP 中写入 0x8010/0x8011 requested profile。
3. 将目标方向的 0x8010:07 或 0x8011:07 bit1 置 1。
4. 写 0x8010:01 = 1 或 0x8011:01 = 1 apply。
5. 读取 0x8010/0x8011:02，确认 Status = 0。
6. 读取 0x8010/0x8011:12，确认 Active profile word 中 OptionFlags 的 bit1 已生效。示例：保持其他方向选项不变，只打开 RxPDO 4 字节对齐：
text Copy old = read_u8(0x8011:07)
write_u8(0x8011:07, old | 0x02)
write_u8(0x8011:01, 1)
check read_u8(0x8011:02) == 0示例：关闭 TxPDO 4 字节对齐：
text Copy old = read_u8(0x8010:07)
write_u8(0x8010:07, old & ~0x02)
write_u8(0x8010:01, 1)
check read_u8(0x8010:02) == 0开启后，发送端必须把每个帧包补齐到 4 字节边界，padding 字节必须写 0，并且 padding 字节计入固定头部 payload_len。接收端解析下一包时也必须使用对齐后的 packet_bytes，不能只按原始 CAN 数据长度前进。
长度示例：
7.4 时间戳字段
TSF 决定 CAN_FRAME 中是否携带时间戳字段。普通 TxPDO 上传方向中，时间戳用于描述从站接收 CAN 帧的时间；RxPDO 下发方向中，TSF_NONE 表示立即发送，TSF_FULL64 可被预约发送格式复用。
TxPDO 中同一 Packet sequence 内的 delta16/delta32 以该周期首个可用时间基准为参考。主站用于排序和诊断时应按无符号差值处理 wrap。若主站不需要时间戳，建议使用 profile 0/4，减少每帧开销。
RxPDO 预约发送只使用 TSF_FULL64 的 8B 字段，并要求格式如下：
text Copy format:u8 = 1
flags:u8 = 0
tag:u16
offset_ns:u32offset_ns 表示相对下一次 SYNC0 周期起点的目标相位。该格式不是绝对时间戳；如果目标相位已经错过，固件不会把帧延迟到下一个周期补发，主站应预留足够相位余量。
8. 封装 Profile 与方向选项
0x8010 控制 TxPDO profile，0x8011 控制 RxPDO profile。当前出厂支持以下 profile：
方向选项由 0x8010/0x8011:07 Option flags 控制。0x8010 作用于 TxPDO/SM3/Input 上传方向，0x8011 作用于 RxPDO/SM2/Output 下发方向。
8.1 Option flags bit 表
Option flags 是 8 bit 位图。写 requested value 不代表配置已经生效。
!!! caution "必须 apply 并回读"
写入选项后必须执行 0x8010:01=1 或 0x8011:01=1。只有 :02=0 且 :12 Active profile word 与预期一致，才能使用新布局。保留位必须保持 0，修改单一选项时应 read-modify-write。
常用写入值：
能力判断：
当前能力掩码以 0xF000 为准。主站应先读取能力对象，再选择 profile 和 option flags。
!!! important "CRC 默认策略"
V1 与 V2 默认都关闭 payload CRC16。关闭时 TxPDO 的 payload_crc16 必须为 0，固件对主站 RxPDO 中的该字段直接跳过；需要 CRC 保护时，主站必须主动清除 NO_CRC16_ENABLE。
8.2 不配置时的默认开关状态
如果主站不写 0x8010/0x8011 的 profile 相关 SDO，设备对象字典中的 requested 默认值如下。注意：0xF000 表示“支持能力”，不表示默认启用；真正启用状态由 0x8010/0x8011 的 requested profile 和 apply 后的 active readback 决定。
推荐主站不要依赖“隐式默认已经生效”的假设。启动时应显式配置 0x1C12/0x1C13、写入 0x8010/0x8011:03..07，再写 0x8010/0x8011:01=1 apply，并读取 :09..12 确认 active 状态。
9. 保留协议值
OptionFlags.bit0、header_flags.bit2 和 KIND=1..3 当前均为保留值，必须写0。固件不会生成逐帧发送结果包；主站应通过CAN对端响应确认业务闭环，并通过PDO通道状态和SDO诊断对象观察FIFO、Bus Off和拥塞。
10. CRC 与完整性策略
默认不为每个 CAN_FRAME 添加 CRC32。
原因：
CAN/CAN FD 总线本身已有 CAN CRC。
EtherCAT 帧已有链路 FCS 和 working counter。
per-frame CRC32 会增加 4B/帧，classic 8B 标准帧开销从 12B 增加到 16B，约 33%。
逐帧 CRC32 会增加 1ms 周期中的小包计算抖动。
默认使用ActiveLayoutCrc校验PDO layout合约，并使用双序号与长度检查运行期映像；默认V1关闭payload_crc16以缩短热路径。需要额外检测payload内存破坏时，清除OptionFlags.bit2即可恢复CRC-16/CCITT-FALSE；CRC开关不会改变已经选定的头部版本或长度。
11. 多通道共享预算
PDO 不再给每路 CAN 固定槽位。调度器按帧区字节预算工作：
text Copy frame_area = ActivePDOBytes - HeaderBytes
reserved_bytes = enabled_channel_count * policy_reserved_bytes
shared_bytes = frame_area - reserved_bytes预算策略：
一条 CAN_FRAME 必须整体放入本周期帧区，不允许跨周期拆分。如果空间不足，设备设置 STREAM_TRUNCATED，增加 overflow_sat 和 SDO PDOOverflowCounter。
12. SDO 对象字典
前面的章节描述周期 PDO 数据，也就是 OP 运行后每个 EtherCAT 周期会交换的字节。SDO 对象字典是配置和诊断入口：进入 OP 前用它设置 PDO profile 和 MCAN 参数，运行中用它读取能力、错误计数和详细状态。读者如果只需要查对象，可以直接从本章按对象号定位；如果正在做 bring-up，建议先看 13.1、13.2、13.4、13.8。
本章只列出面向客户集成的公开对象。未列出的对象属于制造商保留接口，不构成兼容性承诺，也不应由客户程序读写。表中 U8/U16/U32 分别表示无符号 8/16/32 bit。
12.1 按索引快速查找
PDF阅读器建议优先使用左侧“书签/章节目录”。已知对象地址时，使用完整十六进制字符串搜索，例如0x8010:07、0xF000:16；只知道功能时，可搜索下表中的中文或英文关键词。表内范围同时列出各成员地址，确保搜索0x8002或0x9023也能直接命中。
常用子索引入口：
12.1.1 对象总览
12.2 0x8010/0x8011 PDO Profile Control
0x8010 控制 TxPDO/Input 方向，数据流为 S2M；0x8011 控制 RxPDO/Output 方向，数据流为 M2S。SI1/3/4/5/6/7/8 为主站写入的 requested 配置或命令，SI2/9..16 为从站返回的状态和 active readback。
Status 常用值：
Active profile word 打包格式：
Command 位定义：
Last PDO error 常用值：
PDO error counter 统计解析、CRC、非法字段等封装层错误；PDO overflow counter 统计本周期帧区不足、TX/RX 背压导致的溢出或丢弃。现场排查时先看 Status，再看 LastPDOError 和两个计数器是否持续增加。
12.2.1 0x8021..0x8024 MCAN Data Path Control
0x8021..0x8024 分别对应 MCAN0..MCAN3。普通应用保持固件默认值即可；只有在真实 CAN/CAN FD 负载测试表明单周期服务预算不足时，才建议显式覆盖。该对象不改变位时序、过滤器或 Message RAM 配置。
面向客户应用的稳定子索引如下；对象中的其他子索引属于高级策略或保留扩展，不构成客户接口承诺。
IgH MCAN Port API 的以下调用会使用这些索引：
调用任一预算设置函数后，igh_mcan_port_apply_config() 还会为对应通道写 SI1=1，最后写 SI2=1。默认配置不会写 0x8021..0x8024，因此旧固件和设备出厂默认策略不受影响。提高预算可能增大瞬时 CAN 总线突发和 CPU 服务量，必须使用真实负载复测丢帧计数和延迟长尾。
12.2.2 数据面预算配置顺序
手动配置时按以下顺序执行：
确认设备固件提供目标对象；旧固件返回“对象不存在”时应保留默认策略，而不是让整套启动失败。
写 SI1=1。
只写需要覆盖的 SI5 和/或 SI12，取值范围为 0..8。
写 SI2=1 应用。
读取 SI3 和 SI20，确认应用成功并回读生效值。
12.2.3 制造商测试与维护对象
数据面旁路测试、直接寄存器访问、持久化维护和制造流程对象仅供制造商支持使用。客户应用不得依赖或写入这些对象；需要进一步诊断时，请读取 0x9011、0x9020..0x9023、标准状态和错误计数，并导出运行日志。
0x9011 用于观察中断计数、PDI/DC 相位和固件关键路径的最坏耗时。除 Clear command 外，下列字段均只读。耗时字段单位为 CPU cycle，可使用 0x8000:04 返回的 CPU 时钟换算；未启用对应测量功能时，相关字段可能保持 0。
未列出的子索引为兼容或制造商诊断扩展，客户程序不得解释其位布局。
12.2.5 0x9020..0x9023 MCAN Data Path Diagnostics
0x9020..0x9023 分别对应 MCAN0..MCAN3，用于判断瓶颈来自 CAN 接收积压、PDO 空间、MCAN TX 背压、bus-off 还是通道服务预算。
RX cache high watermark 持续接近缓存上限且 RX dropped total 增加，表示 CAN 输入或打包速度超过当前配置能力；TX FIFO full count 增加则表示 CAN 总线发送能力不足或下游未应答。两者应与 0x8010/0x8011 的 overflow counter 和主站 WKC 一起判断。
12.3 0x8000 System Config
CAN pin rotation 只允许在芯片/板级固定 CAN 引脚组之间旋转逻辑通道，不提供任意 GPIO 复用配置。
12.4 0x8001..0x8004 MCAN Channel Config
每路通道结构相同，0x8001 对应 CAN0，0x8004 对应 CAN3。
对象完整子项按功能分组如下。普通客户通常只需要配置 SI15/16/19/20 和必要的 FIFO/Queue 参数；滤波器、TSU、Timeout 属于高级配置。
通道命令与状态：
Node mode 取值：
手动 bit timing 仅在 SI7 Bit timing mode = 1 时生效。自动模式下主站配置 Nominal/Data bitrate 和采样点范围，固件根据 MCAN 源时钟求解 BRP/TSEG/SJW。采样点范围应按对端设备配置：已知对端采样点时建议把 min/max 都写成目标采样点；未知时先按对端文档推荐值配置并验证收发质量。手动模式下使用 SI25..32。
滤波器全局字段：
滤波器编辑窗口：
Entry cmd：
Entry status：
典型过滤器配置流程：
读取 Std list max / Ext list max，确认容量。
写 Std filter count 或 Ext filter count。
写 current index。
写 filter type/action/sync/id1/id2。
写 entry cmd = 2 保存当前索引。
重复配置多个条目。
写 Apply command = 1 让通道配置生效。
如需掉电保存，写 Flash command bit0 = 1。
RAM/FIFO/Buffer 字段：
注意：表中的 SI 是十进制子项号；很多主站界面会用十六进制显示。用户常说的 0x41/0x42/0x44 分别就是十进制 65/66/68，对应 RX FIFO0、RX FIFO1、RX Buffer 的元素数据区大小。它们只决定 MCAN Message RAM 里每个元素可容纳的最大数据字节数，不决定 PDO 中单帧 CAN FD 的 DLC；实际 DLC 仍由 RxPDO/TxPDO 帧包里的 DLC 字段决定。
data size 使用 HPM MCAN 驱动枚举，不是字节数本身。常用枚举如下：
Message RAM 预算由元素数量和 data size 共同决定。CAN FD 通用默认建议 RXFIFO0=48, RXFIFO1=12, RXBUF=12, TXFIFO=32, TXBUF=0, TXEVENT=32, data size=7；classic CAN 可把 data size 降到 0，以节省 RAM 给更多元素。配置非法或超过通道 Message RAM 预算时，Apply status 会返回错误，运行配置不会切换到新值。
Timestamp/TSU/Timeout 字段：
TDC 策略：
CAN FD 默认 TDC enable=1。
数据段低于 5M 时，主站可通过 SDO 关闭 TDC。
数据段达到 5M 及以上时，固件忽略 TDC enable=0 并强制开启 TDC。
TDC offset/filter 默认 0，表示由 HPM MCAN 驱动按实际数据段时序自动计算。非 0 的 TDC offset/filter 仍被固件保留并下发给 MCAN 驱动，供现场专家调试使用。
手动覆盖时建议 offset/filter 成对配置。
该对象为 RO，方向为 S2M，用于主站按需读取通道详细状态。
12.6 制造商维护接口
!!! danger "非公开接口"
寄存器访问、工厂维护和持久化修复接口不属于公开产品 API。客户现场不得通过 SDO 改写控制器寄存器或设备存储区；恢复或深度诊断必须使用官方服务流程。
12.7 0xF000 Device Objects
主站必须读取 0xF000 能力对象后再选择 PDO profile。
该对象为 RO，方向为 S2M，用于主站识别设备能力、版本和协议上限。
PDO 能力与上限：
Encapsulation profile mask：
PDO option flags mask：
PDO feature flags：
Device service flags：
RxPDO 预约发送复用动态帧 TSF_FULL64 字段，不改变普通 CAN frame 包结构：
text Copy format:u8 = 1
flags:u8 = 0
tag:u16
offset_ns:u32TSF_NONE 仍为立即发送；TSF_FULL64 format=1 表示预约到下一次 SYNC0 周期的 offset_ns 相位发送。同一相位按 PDO 帧顺序排队。
预约发送实现约束：
主站必须先确认 0xF000:16 的 bit8（掩码 0x00000100）已置位，表示支持 RxPDO TSF 预约发送。
offset_ns 以当前 EtherCAT DC/SYNC0 周期为参考，推荐先使用 100000ns 或更大的保守相位做 bring-up。设备按 SYNC0 相位调度预约帧；已超过目标相位的帧不会跨周期补发，主站应预留足够的 offset_ns 余量。
预约发送与直接发送共用 CAN 发送路径；当通道拥塞或发送异常时，通过 PDO 状态和 SDO 诊断计数反馈。
当主站停止后，ESC 过程数据区可能保持最后一帧 RxPDO 镜像；固件将完全相同的重复镜像作为幂等 no-op，不记为真实解析错误。
12.8 预约发送与直接发送实时性对比
预约发送不能补偿不稳定的主站周期。启用前应先确认 EtherCAT 周期、DC 状态和
WKC 稳定，并用 CAN 分析仪在实际线缆和负载下验证发送相位。
13. 技术规格
14. 修订历史
