做运动控制、伺服驱动或者远程IO设备的朋友这两年应该明显感受到一个趋势国产化方案从“能不能用”已经跨到了“好不好用”的阶段。手里这颗FCE1100国产EtherCAT从站芯片配上FCP32C335国产DSP组合起来就是一套很典型的国产功能板架构。FCE1100管实时通信FCP32C335管应用控制两颗芯片各司其职测试流程自然也和传统单MCU方案不一样。我最近正好完整跑了一遍这套功能板的从零到量产前的测试把流程、工具、踩过的坑都整理出来给正在做类似方案的工程师省点时间。这套测试流程主要解决三个问题一是验证FCE1100作为从站控制器能不能稳定接入EtherCAT网络二是验证FCP32C335和FCE1100之间的数据链路有没有隐性Bug三是验证整块板子在真实应用场景下扛不扛得住长时间运行。如果你正在做国产伺服驱动器、步进驱动器、现场IO从站或者任何需要走EtherCAT的控制器这篇内容可以直接拿来当测试大纲用。1. 方案背景与整体设计思路1.1 为什么选“EtherCAT从站芯片 DSP”双芯架构先聊一个很多人会问的问题现在不少MCU也集成了EtherCAT从站控制器比如某些STM32和瑞萨芯片为什么还要专门用一颗FCE1100再加一颗DSP答案是分工和稳定性。EtherCAT的从站侧需要硬件处理以太网帧、FMMU地址映射、SM同步管理、DC分布时钟这些机制这些功能如果全靠MCU软件去跑实时性很悬。FCE1100这种专用从站芯片本质上是把协议处理从应用处理器里剥离出来DSP只需要通过SPI或者并行总线读写过程数据就行不用关心EtherCAT帧长什么样。FCP32C335这颗DSP定位上属于C2000类控制器的替代路线有独立的PWM、ADC、QEP等外设专门用来跑电流环、速度环、位置环这类控制算法。双芯架构下控制算法和通信协议栈互不干扰调试的时候也能分头定位问题通信有问题查FCE1100那边控制有问题查DSP这边不用把两坨逻辑纠缠在一起Debug。还有一个现实原因从供货安全和成本角度国产从站芯片加国产DSP的组合整板国产化率更高客户验收也更好过。我接触的几个伺服项目业主明确要求核心器件国产化FCE1100和FCP32C335这种组合就成了首选。1.2 功能板的整体数据流这块功能板的信息流很简单但每一环都是测试重点EtherCAT主站比如倍福TwinCAT发出标准EtherCAT帧帧通过网线进入板上的百兆PHY芯片转换成MII/RMII信号FCE1100从站控制器解析帧从中提取出本站的PDO输出数据放入内部DPRAMFCP32C335 DSP通过SPI读取DPRAM中的输出数据跑控制算法DSP把采样到的实际位置、电流等数据写回从站芯片DPRAMFCE1100在下一帧EtherCAT周期把这些数据作为PDO输入发送给主站整条链路里最容易被忽视的是PHY和网络变压器部分。EtherCAT虽然走的是标准以太网物理层但用法和普通以太网不太一样主站和从站之间是菊花链拓扑每站需要两路网口外部PHY芯片的差分对、网络变压器的中心抽头接线都必须严格按手册来。我测试中发现很多“扫描不到从站”的问题最后都查到了PHY电路上而不是协议栈。1.3 测试流程的设计原则这套测试流程我按“从能通电到能扛活”的节奏来设计分四个阶段上电最小系统测试验证电源、时钟、复位、JTAG、双芯通信接口EtherCAT协议功能测试验证从站识别、状态机切换、PDO通信、DC同步应用功能测试验证DSP外设和EtherCAT数据的联动比如PWM输出、ADC采样压力与可靠性测试长时间运行、异常断电、网线热插拔等场景每个阶段都有独立的判定标准前一个阶段没过绝不留到后一个阶段再排查。这个原则听起来死板实际能省很多时间。比如DC同步抖动大如果底层SPI通信时序有问题你怎么调中断优先级都白搭。先把基础打牢再往上走这是我在多个项目里验证过的节奏。2. 测试环境与工具链准备2.1 硬件测试清单一个完整的EtherCAT从站测试环境硬件上不只是功能板本身。我常用的配置如下功能板待测的核心板加底板带完整电源电路直流电源至少两路一路给板子系统供电一路给主站工控机隔离供电主站设备工控机装TwinCAT或者带EtherCAT主站功能的PLC示波器至少4通道带宽100MHz以上测SYNC0同步信号和SPI时序够用逻辑分析仪建议16通道以上抓SPI和MII总线用EtherCAT抓包工具支持时间戳的工业以太网分析仪比如带EtherCAT驱动的专用网卡加Wireshark万用表、电烙铁、飞线排查硬件问题必备这里特别提醒一句EtherCAT网线一定要用质量好的屏蔽双绞线而且不要在系统上电状态下频繁热插拔。从站PHY芯片其实挺脆弱的我之前有一块板子反复热插拔后PHY就莫名奇妙挂了换芯片才恢复正常。2.2 软件工具链软件方面我建议按下面的组合来主站软件TwinCAT 3免费授权足够测试用EtherCAT诊断窗口做得非常直观从站XML文件厂商会提供FCE1100配套的从站描述文件或者用SSC工具自己配置生成DSP开发环境FCP32C335配套的IDE通常兼容TI CCS的工程调试器通用从站代码FCE1100一般会配套类似SSC的从站协议栈源码包含EtherCAT状态机处理和邮箱通信处理抓包工具Wireshark加EtherCAT解析插件或者专用分析仪配套软件从站XML文件是个很容易踩坑的地方。EtherCAT主站靠XML识别从站的PDO映射、邮箱能力、厂商信息。如果XML里声明的SM通道数量、PDO长度和实际固件不一致主站就会报错甚至把从站识别成未知设备。我的习惯是XML文件改一处就重新生成EEPROM镜像并烧录同时用主站工具回读校验绝不凭记忆改配置。2.3 为什么不能只靠主站状态码调试很多人习惯只看TwinCAT主站报什么错然后直接按错误码查手册。但EtherCAT的错误很多是链路层问题主站软件能看到的只是“从站无响应”或者“看门狗超时”这类笼统结果。举一个实际例子从站进不了OP状态主站报的是SM看门狗超时。我清掉错误重新进一次还是不行最后用抓包工具看链路层的帧数据才发现是EEPROM里PDO映射长度不对导致SAFEOP到OP时输出数据长度校验失败。这种问题光靠主站诊断窗口根本定位不到。所以测试环境里抓包工具不是可有可无的选配而是必备项。EtherCAT帧在普通千兆网卡上不一定能完整抓下来最好用支持时间戳的专用网卡这样可以精确到纳秒级别分析帧间隔。3. 上电与最小系统测试3.1 电源和复位时序测试拿到功能板第一件事不是插网线也不是烧程序而是拿万用表逐路量电源。FCE1100和FCP32C335都是多电源域器件常见的有3.3V IO电源、1.2V内核电源、1.8V DDR或模拟电源每一路的电压精度和纹波都要有下限和上限。我建议用限流电源给板子上电先限制在额定电流的120%左右防止板上短路把器件烧了。上电后先量各路电压是否在目标值附近然后用示波器看纹波特别是FCP32C335的ADC参考电源纹波太大会直接影响采样精度这个阶段就要发现。复位时序也是重点。部分DSP要求内核电源和IO电源有上电顺序如果先给IO供电、内核还没起来芯片可能锁死表现为JTAG连不上、程序烧不进去。最稳妥的做法是板级设计时就加电源监控芯片统一控制复位如果板子已经做出来了只能靠调试器反复断电重试。我不止一次遇到过JTAG连不上的问题最后发现就是复位时序没满足折腾了整整一天。3.2 时钟与JTAG调试通道验证电源没问题之后用示波器测晶振起振。EtherCAT从站芯片和DSP对时钟要求都比较严格特别是从站芯片它要根据PHY接收的以太网时钟恢复同步所以本地晶振只要频率偏差在合理范围就行不用太夸张。时钟正常后连接调试器烧写一个最简单的GPIO翻转程序。这个程序不需要任何通信功能就是让一个LED或测试点按固定频率翻转。这一步能确认FCP32C335的最小系统完全正常。然后再测FCE1100的复位和晶振确认从站芯片自身处于可工作状态。我的惯例是在测试记录表里截下JTAG连接成功和设备ID识别的截图方便后面追溯。3.3 双芯片通信接口的寄存器级验证FCE1100和FCP32C335之间的PDI接口最常见的实现是SPI从模式。FCE1100作为SPI从设备DSP作为主设备去读写它的寄存器和DPRAM。这一层是整块板子的命脉通信一旦有问题后面所有EtherCAT功能都是空中楼阁。先用逻辑分析仪抓一遍SPI时序确认时钟极性和相位匹配。FCE1100一般支持模式0或模式3具体要看寄存器配置。我踩过的坑是SPI速率调得太高FCE1100没响应DSP读回来全是0xFF降低到1MHz就正常了。如果板子频率已经固定就要查DSP的SPI时钟分频配置。这一阶段建议写一个SPI寄存器读写测试函数能读FCE1100的AL Status寄存器地址0x0130和AL Control寄存器地址0x0120。AL Status寄存器里面有从站当前状态机的值如果SPI通信正常读回来的值应该符合预期。下面是一段简化示例void esc_read_reg(uint16_t addr, uint16_t *val) { // 根据FCE1100数据手册的SPI命令格式拼装读命令 // 通常需要先发送地址再发送读标志然后等待数据返回 // 这里只展示关键流程具体命令字需要对照数据手册确认 uint8_t buf[4]; buf[0] (addr 8) 0xFF; buf[1] addr 0xFF; buf[2] 0x00; // 读命令 buf[3] 0x00; spi_cs_low(); spi_transmit(buf, 4); spi_cs_high(); *val (buf[2] 8) | buf[3]; } uint16_t read_al_status(void) { uint16_t status 0; esc_read_reg(0x0130, status); return status; }这个阶段不需要接EtherCAT主站只需要用调试器读DSP内存确认返回值合理即可。如果读AL Status一直返回0xFFFF或0x0000先查CS片选时序再查SPI引脚复用配置不要先怀疑芯片坏了。4. EtherCAT从站协议功能测试4.1 从站信息与EEPROM验证FCE1100从站芯片通常外挂一颗EEPROM存储从站配置信息包括厂商ID、产品码、PDO映射、邮箱能力等。主站上电扫描时会通过ESC读EEPROM来识别从站。测试这一步先把配套的EEPROM镜像通过主站工具或厂商烧录工具写进去然后重新上电在TwinCAT里扫描设备。如果识别出来的设备名称、厂商ID、产品码完全匹配说明EEPROM和从站芯片基本正常。扫描不到从站首先看功能板上两个网口的Link指示灯是否亮。如果不亮查PHY和网络变压器链路如果亮再查EEPROM烧录是否正确。这里有一个容易被忽略的点EEPROM的CRC校验。很多主站在扫描时会校验EEPROM的CRC如果之前用不完整的镜像烧过CRC算不对主站也会拒绝识别。遇到这种情况用主站工具重新生成并烧录完整的EEPROM镜像就好。另外从站在INIT状态下就可以被主站访问EEPROM不需要先进入PREOP这一点在排查时很有用。4.2 状态机切换测试EtherCAT从站状态机分四态INIT、PREOP、SAFEOP、OP。测试时用TwinCAT的ESC诊断窗口手动切换状态观察从站实际状态。正常流程是INIT到PREOPPREOP到SAFEOPSAFEOP到OP。每切一个状态都读一下AL Status寄存器确认当前状态同时检查AL Error寄存器0x0134有没有异常代码。我遇到最多的是PREOP进SAFEOP失败错误码指向SM通道或者PDO映射长度不匹配。这种问题排查思路很直接把XML里配置的SM通道映射和固件初始化SM的代码逐行对比。状态机测试除了正常路径还要测异常路径。比如在OP状态下直接拔掉网线再插回去看从站能不能自动恢复。这个过程最能暴露看门狗配置的问题。EtherCAT从站在OP状态下如果连续几个周期没有收到主站帧SM看门狗就会超时从站自动降级到SAFEOP或INIT。好的设计是从站能在网线恢复后通过主站的重新配置自动回到OP不需要人工干预。如果做不到就要调整看门狗超时时间或者状态切换逻辑。4.3 PDO映射与过程数据通信PDO是EtherCAT周期通信的核心。测试PDO映射时先在XML里配置好RxPDO和TxPDO。比如一个典型伺服轴控制应用RxPDO目标位置4字节、目标速度4字节、控制字2字节TxPDO实际位置4字节、实际速度4字节、状态字2字节从站固件初始化时要按照XML里的SM配置把DPRAM地址映射好。测试PDO通信时主站往RxPDO写一个固定值从站收到后通过TxPDO回传同样的值比较发送和接收是否一致。我建议在从站固件里加一个回环模式把收到的RxPDO数据原样拷贝到TxPDO缓冲区。这样不需要外接任何执行器就能验证整条PDO链路。测试时可先用TwinCAT在线写入一个值观察回传值再写一个递增序列做批量验证。如果数据错位大概率是字节序或DPRAM偏移不对。EtherCAT数据在网络上是大端顺序但DSP内部处理是按小端转换代码写错会出现高低字节交换的经典问题。4.4 CoE邮箱通信测试除了周期PDOEtherCAT从站通常还要支持非周期邮件通信最常用的是CoE协议也就是CANopen over EtherCAT用来读写对象字典。测试CoE时在TwinCAT里对从站对象字典执行SDO上传和下载操作。我们可以在对象字典里自定义几个测试对象比如一个只读对象存DSP固件版本号一个可写对象存测试标志。实测中发现很多从站SDO通信出问题都是邮箱配置不对。邮箱的SM通道必须配置为邮箱协议模式而且要正确声明支持CoE。这个信息在EEPROM里都有体现如果XML或EEPROM里没声明CoE支持TwinCAT会把发送请求标志为不支持。另外SDO块传输对大对象读写性能要求高连续快速读写时注意从站协议栈的邮箱缓冲区不能开得太小否则会丢请求。4.5 分布时钟与同步测试这一步是EtherCAT从站测试里技术含量最高的部分直接关系到多轴同步性能。EtherCAT DC分布式时钟功能让所有从站共享同一个系统时间输出同步信号SYNC0/SYNC1从站据此对齐输出时刻。先让主站启用DC功能读取从站的系统时间、传输延时等参数TwinCAT会自动计算并补偿。然后用示波器同时测主站的周期信号和从站的SYNC0信号观察两个信号的相位差和抖动。对于伺服应用SYNC0信号的抖动一般要控制在1微秒以内才算合格。如果抖动大先查干扰和电源纹波再查FCP32C335中断响应。FCE1100在SYNC0到来时会拉高一个中断引脚通知DSPDSP中断服务函数里的耗时必须足够短且波动小。如果DSP中断里跑了大段计算或者禁中断时间过长抖动会明显变大。实际测试时我会把中断服务函数精简到只拷贝数据和置标志位真正的控制算法在主循环或者高优先级任务里做。另外多个从站级联时要跑一遍全部从站的DC同步测试而不仅仅测单个站这样才能发现传播延时补偿的累计误差。5. 基于FCP32C335的应用功能测试5.1 控制回路闭环跑通测试EtherCAT测试通过以后就要验证FCP32C335这颗DSP真正干活的环节。最基础的测试是搭一个简单的闭环回路主站通过EtherCAT下发目标值DSP用PWM输出一个占空比经过RC低通滤波变成模拟电压再用ADC采样这个电压把实际值通过PDO上传回主站。这个测试完整覆盖了从站读数据、DSP控制、外设输出、ADC采样、数据回传的整条链路。测试时先手动给定一个目标值观察回传的实际值是否稳定到目标附近。如果实际值一直在波动先看PWM频率和滤波器截止频率是否匹配再看ADC采样触发是否和PWM同步。FCP32C335的ADC如果和PWM触发不同步采样时刻落在PWM开关噪声上反馈值会忽高忽低。我在测试时发现过一种情况主站下发目标值后实际值能跟上但有个明显的周期性毛刺。追了一圈发现是FCE1100的SYNC0中断和DSP内部ADC中断优先级冲突导致偶尔一次控制周期被拖长。把ADC中断优先级调低并把关键计算搬进同步中断后毛刺就消失了。这种问题只有闭环测试才能暴露出来。5.2 编码器接口与位置反馈测试如果功能板面向伺服应用FCP32C335的QEP正交编码器接口是必测项。测试时用信号发生器模拟编码器A/B/Z信号也可以接一个真实的增量式编码器手动旋转。DSP通过QEP模块计算位置和速度然后通过EtherCAT的TxPDO上报主站。主站同时下发期望位置比对主站写的值和从站上报值的偏差。这里重点测几个场景正向旋转、反向旋转、经过Z脉冲清零、高速旋转时的计数有没有丢步。有一个容易踩的坑编码器接线顺序反了或者QEP配置的方向极性反了会导致位置值越走越偏。解决方案是在DSP固件里加入方向检测逻辑或者用QEP的计数方向引脚判断并在系统参数里提供极性反转选项。另外如果编码器信号长距离传输注意差分接收和滤波电容的取值电容太大会导致高速时沿变缓丢脉冲。5.3 长时间运行与数据一致性压力测试功能测试全部通过后把板子接到真实主站环境里跑连续运行测试。我习惯跑24小时甚至48小时主站按照项目实际周期下发数据从站持续运行控制算法。数据一致性检查方法是从站固件里维护一个滚动计数器每收到一个PDO周期就加1并通过TxPDO上报。主站侧检测这个计数器是否连续递增一旦发现跳变或重复说明链路上出现了丢帧或重复帧。我测试时有一个常见情况计数器偶尔跳变但网络状态显示一切正常。排查后发现是从站固件里看门狗处理逻辑有Bug在异常情况下重入了初始化流程导致计数器清零。这种偶发问题靠肉眼盯状态很难发现必须靠计数器比对和日志记录才能抓住。压力测试期间还要同时记录板温、电源电流、SYNC0抖动看长时间运行后性能是否漂移。6. 常见问题排查与实测经验6.1 问题速查表现象可能原因排查手段主站扫描不到从站PHY差分线接反、网络变压器虚焊、EEPROM无效检查PHY Link灯、示波器测MII/RMII信号、重新烧录EEPROM从站卡在PREOP进不了SAFEOPSM通道未配置、PDO映射长度不匹配、邮箱配置错误对比XML和固件配置、查看AL Error寄存器、抓EtherCAT帧分析OP状态但PDO数据不刷新DC同步未启用、看门狗配置错误、SPI读写冲突检查DC参数、示波器看SYNC0、逻辑分析仪抓SPISYNC0抖动大电源纹波、DSP中断响应太慢、FCE1100中断被屏蔽示波器测纹波、精简中断函数、调整中断优先级SDO读写超时邮箱SM配置错误、对象字典索引错误、块传输缓冲不足用TwinCAT在线扫描对象字典、增大邮箱缓冲我自己实测下来出现频率最高的其实是第一行和第三行。PHY电路问题往往在原理图阶段就有隐患比如差分线不按100欧姆阻抗布线、网络变压器中心抽头处理不对。功能板测试流程里一定要包含一次PHY信号眼图测试或者至少是MII/RMII时钟信号观察不要偷懒。6.2 排查技巧和避坑心得做EtherCAT从站测试心态要稳。EtherCAT链路层的问题经常是间接原因造成的不是非黑即白。我总结三个技巧第一从站侧所有状态变化都要打日志。FCE1100的AL状态、错误码、SPI通信失败次数都记录下来通过调试器串口输出。很多偶发问题只有日志才能还原现场。第二用抓包工具保留“犯罪现场”。当从站异常时立刻停止主站刷新用分析仪把最后一段EtherCAT帧存下来。分析帧里主站请求了什么、从站回了什么很多问题一眼就能看出来。第三最小化复现。我遇到过一个问题功能板一切正常但装了底板后从站偶发掉线。开始怀疑底板干扰后来把外壳装上才稳定。最后排查发现是底板没有良好的接地EtherCAT网口的共模干扰过大。这种系统性干扰问题靠逐层排除法能省很多时间。6.3 关于国产芯片资料的心得国产从站芯片和DSP配套资料相比国际大厂可能会零散一点但这两年已经好很多了。FCE1100的寄存器说明和示例代码基本能覆盖开发需求FCP32C335的外设库也兼容主流DSP开发习惯。如果遇到手册没讲清楚的地方我的经验是直接看配套的从站协议栈源码它比手册更接近真实行为。比如FCE1100的EEPROM读写在协议栈里会有完整示例比手册里的时序图直观得多。另外厂商FAE的支持速度也很快碰到疑难杂症不要不好意思问。7. 测试记录与判定标准7.1 测试项与通过标准建议测试流程要能落地必须把每一项的判定标准量化。我常用的测试项清单如下测试阶段测试项通过标准上电最小系统电源电压/纹波各路电压偏差小于5%纹波小于50mV上电最小系统复位时序满足芯片手册时序要求示波器截图存档双芯通信SPI寄存器读写读AL Status返回值正确连续读写1000次无错误EtherCAT协议从站识别主站识别名称/厂商ID/产品码与XML一致EtherCAT协议状态机切换四态切换无报错异常恢复时间小于1秒EtherCAT协议PDO回环连续100万个周期数据无错位、无丢帧EtherCAT协议DC同步SYNC0抖动小于1微秒长时间漂移小于5微秒应用功能闭环控制实际值稳态误差小于设定阈值动态响应符合预期应用功能编码器反馈位置计数无丢步正反向对称可靠性24小时压力滚动计数器无跳变板温在允许范围内这个表你可以按自己项目调整但原则是一定要量化和可复核。比如“工作正常”这种话不能当标准“连续100万周期无错误”才是标准。7.2 把测试流程固化到产线研发阶段的测试流程跑顺了不代表产线就能直接照搬。产线测试追求速度快、操作门槛低需要把测试步骤固化到自动化工具里。我建议用Python脚本通过TwinCAT ADS接口自动执行测试读取从站状态、写PDO数据、记录结果到Excel或者数据库。产线工人只需要把板子接上电源和网线点击“开始测试”几分钟后屏幕上显示PASS或者FAIL。这样既提高了效率又避免了人工操作的误判。固件里也要预留产线测试模式。比如通过CoE写入一个测试使能对象从站自动执行自检并返回结果。这样产线不需要理解EtherCAT协议细节只需要看结果。最后再分享一个个人经验测试流程本身也要持续迭代。每发现一个新问题就把复现步骤和排查方法补充到测试文档里形成问题库。这样同一个坑不会踩第二次团队里的新工程师也能快速上手。我这套FCE1100和FCP32C335功能板的测试流程就是在一个个具体问题里打磨出来的过程很折腾但跑顺之后的稳定感值得。
EtherCAT从站芯片与DSP双核架构功能板测试全流程实战
做运动控制、伺服驱动或者远程IO设备的朋友这两年应该明显感受到一个趋势国产化方案从“能不能用”已经跨到了“好不好用”的阶段。手里这颗FCE1100国产EtherCAT从站芯片配上FCP32C335国产DSP组合起来就是一套很典型的国产功能板架构。FCE1100管实时通信FCP32C335管应用控制两颗芯片各司其职测试流程自然也和传统单MCU方案不一样。我最近正好完整跑了一遍这套功能板的从零到量产前的测试把流程、工具、踩过的坑都整理出来给正在做类似方案的工程师省点时间。这套测试流程主要解决三个问题一是验证FCE1100作为从站控制器能不能稳定接入EtherCAT网络二是验证FCP32C335和FCE1100之间的数据链路有没有隐性Bug三是验证整块板子在真实应用场景下扛不扛得住长时间运行。如果你正在做国产伺服驱动器、步进驱动器、现场IO从站或者任何需要走EtherCAT的控制器这篇内容可以直接拿来当测试大纲用。1. 方案背景与整体设计思路1.1 为什么选“EtherCAT从站芯片 DSP”双芯架构先聊一个很多人会问的问题现在不少MCU也集成了EtherCAT从站控制器比如某些STM32和瑞萨芯片为什么还要专门用一颗FCE1100再加一颗DSP答案是分工和稳定性。EtherCAT的从站侧需要硬件处理以太网帧、FMMU地址映射、SM同步管理、DC分布时钟这些机制这些功能如果全靠MCU软件去跑实时性很悬。FCE1100这种专用从站芯片本质上是把协议处理从应用处理器里剥离出来DSP只需要通过SPI或者并行总线读写过程数据就行不用关心EtherCAT帧长什么样。FCP32C335这颗DSP定位上属于C2000类控制器的替代路线有独立的PWM、ADC、QEP等外设专门用来跑电流环、速度环、位置环这类控制算法。双芯架构下控制算法和通信协议栈互不干扰调试的时候也能分头定位问题通信有问题查FCE1100那边控制有问题查DSP这边不用把两坨逻辑纠缠在一起Debug。还有一个现实原因从供货安全和成本角度国产从站芯片加国产DSP的组合整板国产化率更高客户验收也更好过。我接触的几个伺服项目业主明确要求核心器件国产化FCE1100和FCP32C335这种组合就成了首选。1.2 功能板的整体数据流这块功能板的信息流很简单但每一环都是测试重点EtherCAT主站比如倍福TwinCAT发出标准EtherCAT帧帧通过网线进入板上的百兆PHY芯片转换成MII/RMII信号FCE1100从站控制器解析帧从中提取出本站的PDO输出数据放入内部DPRAMFCP32C335 DSP通过SPI读取DPRAM中的输出数据跑控制算法DSP把采样到的实际位置、电流等数据写回从站芯片DPRAMFCE1100在下一帧EtherCAT周期把这些数据作为PDO输入发送给主站整条链路里最容易被忽视的是PHY和网络变压器部分。EtherCAT虽然走的是标准以太网物理层但用法和普通以太网不太一样主站和从站之间是菊花链拓扑每站需要两路网口外部PHY芯片的差分对、网络变压器的中心抽头接线都必须严格按手册来。我测试中发现很多“扫描不到从站”的问题最后都查到了PHY电路上而不是协议栈。1.3 测试流程的设计原则这套测试流程我按“从能通电到能扛活”的节奏来设计分四个阶段上电最小系统测试验证电源、时钟、复位、JTAG、双芯通信接口EtherCAT协议功能测试验证从站识别、状态机切换、PDO通信、DC同步应用功能测试验证DSP外设和EtherCAT数据的联动比如PWM输出、ADC采样压力与可靠性测试长时间运行、异常断电、网线热插拔等场景每个阶段都有独立的判定标准前一个阶段没过绝不留到后一个阶段再排查。这个原则听起来死板实际能省很多时间。比如DC同步抖动大如果底层SPI通信时序有问题你怎么调中断优先级都白搭。先把基础打牢再往上走这是我在多个项目里验证过的节奏。2. 测试环境与工具链准备2.1 硬件测试清单一个完整的EtherCAT从站测试环境硬件上不只是功能板本身。我常用的配置如下功能板待测的核心板加底板带完整电源电路直流电源至少两路一路给板子系统供电一路给主站工控机隔离供电主站设备工控机装TwinCAT或者带EtherCAT主站功能的PLC示波器至少4通道带宽100MHz以上测SYNC0同步信号和SPI时序够用逻辑分析仪建议16通道以上抓SPI和MII总线用EtherCAT抓包工具支持时间戳的工业以太网分析仪比如带EtherCAT驱动的专用网卡加Wireshark万用表、电烙铁、飞线排查硬件问题必备这里特别提醒一句EtherCAT网线一定要用质量好的屏蔽双绞线而且不要在系统上电状态下频繁热插拔。从站PHY芯片其实挺脆弱的我之前有一块板子反复热插拔后PHY就莫名奇妙挂了换芯片才恢复正常。2.2 软件工具链软件方面我建议按下面的组合来主站软件TwinCAT 3免费授权足够测试用EtherCAT诊断窗口做得非常直观从站XML文件厂商会提供FCE1100配套的从站描述文件或者用SSC工具自己配置生成DSP开发环境FCP32C335配套的IDE通常兼容TI CCS的工程调试器通用从站代码FCE1100一般会配套类似SSC的从站协议栈源码包含EtherCAT状态机处理和邮箱通信处理抓包工具Wireshark加EtherCAT解析插件或者专用分析仪配套软件从站XML文件是个很容易踩坑的地方。EtherCAT主站靠XML识别从站的PDO映射、邮箱能力、厂商信息。如果XML里声明的SM通道数量、PDO长度和实际固件不一致主站就会报错甚至把从站识别成未知设备。我的习惯是XML文件改一处就重新生成EEPROM镜像并烧录同时用主站工具回读校验绝不凭记忆改配置。2.3 为什么不能只靠主站状态码调试很多人习惯只看TwinCAT主站报什么错然后直接按错误码查手册。但EtherCAT的错误很多是链路层问题主站软件能看到的只是“从站无响应”或者“看门狗超时”这类笼统结果。举一个实际例子从站进不了OP状态主站报的是SM看门狗超时。我清掉错误重新进一次还是不行最后用抓包工具看链路层的帧数据才发现是EEPROM里PDO映射长度不对导致SAFEOP到OP时输出数据长度校验失败。这种问题光靠主站诊断窗口根本定位不到。所以测试环境里抓包工具不是可有可无的选配而是必备项。EtherCAT帧在普通千兆网卡上不一定能完整抓下来最好用支持时间戳的专用网卡这样可以精确到纳秒级别分析帧间隔。3. 上电与最小系统测试3.1 电源和复位时序测试拿到功能板第一件事不是插网线也不是烧程序而是拿万用表逐路量电源。FCE1100和FCP32C335都是多电源域器件常见的有3.3V IO电源、1.2V内核电源、1.8V DDR或模拟电源每一路的电压精度和纹波都要有下限和上限。我建议用限流电源给板子上电先限制在额定电流的120%左右防止板上短路把器件烧了。上电后先量各路电压是否在目标值附近然后用示波器看纹波特别是FCP32C335的ADC参考电源纹波太大会直接影响采样精度这个阶段就要发现。复位时序也是重点。部分DSP要求内核电源和IO电源有上电顺序如果先给IO供电、内核还没起来芯片可能锁死表现为JTAG连不上、程序烧不进去。最稳妥的做法是板级设计时就加电源监控芯片统一控制复位如果板子已经做出来了只能靠调试器反复断电重试。我不止一次遇到过JTAG连不上的问题最后发现就是复位时序没满足折腾了整整一天。3.2 时钟与JTAG调试通道验证电源没问题之后用示波器测晶振起振。EtherCAT从站芯片和DSP对时钟要求都比较严格特别是从站芯片它要根据PHY接收的以太网时钟恢复同步所以本地晶振只要频率偏差在合理范围就行不用太夸张。时钟正常后连接调试器烧写一个最简单的GPIO翻转程序。这个程序不需要任何通信功能就是让一个LED或测试点按固定频率翻转。这一步能确认FCP32C335的最小系统完全正常。然后再测FCE1100的复位和晶振确认从站芯片自身处于可工作状态。我的惯例是在测试记录表里截下JTAG连接成功和设备ID识别的截图方便后面追溯。3.3 双芯片通信接口的寄存器级验证FCE1100和FCP32C335之间的PDI接口最常见的实现是SPI从模式。FCE1100作为SPI从设备DSP作为主设备去读写它的寄存器和DPRAM。这一层是整块板子的命脉通信一旦有问题后面所有EtherCAT功能都是空中楼阁。先用逻辑分析仪抓一遍SPI时序确认时钟极性和相位匹配。FCE1100一般支持模式0或模式3具体要看寄存器配置。我踩过的坑是SPI速率调得太高FCE1100没响应DSP读回来全是0xFF降低到1MHz就正常了。如果板子频率已经固定就要查DSP的SPI时钟分频配置。这一阶段建议写一个SPI寄存器读写测试函数能读FCE1100的AL Status寄存器地址0x0130和AL Control寄存器地址0x0120。AL Status寄存器里面有从站当前状态机的值如果SPI通信正常读回来的值应该符合预期。下面是一段简化示例void esc_read_reg(uint16_t addr, uint16_t *val) { // 根据FCE1100数据手册的SPI命令格式拼装读命令 // 通常需要先发送地址再发送读标志然后等待数据返回 // 这里只展示关键流程具体命令字需要对照数据手册确认 uint8_t buf[4]; buf[0] (addr 8) 0xFF; buf[1] addr 0xFF; buf[2] 0x00; // 读命令 buf[3] 0x00; spi_cs_low(); spi_transmit(buf, 4); spi_cs_high(); *val (buf[2] 8) | buf[3]; } uint16_t read_al_status(void) { uint16_t status 0; esc_read_reg(0x0130, status); return status; }这个阶段不需要接EtherCAT主站只需要用调试器读DSP内存确认返回值合理即可。如果读AL Status一直返回0xFFFF或0x0000先查CS片选时序再查SPI引脚复用配置不要先怀疑芯片坏了。4. EtherCAT从站协议功能测试4.1 从站信息与EEPROM验证FCE1100从站芯片通常外挂一颗EEPROM存储从站配置信息包括厂商ID、产品码、PDO映射、邮箱能力等。主站上电扫描时会通过ESC读EEPROM来识别从站。测试这一步先把配套的EEPROM镜像通过主站工具或厂商烧录工具写进去然后重新上电在TwinCAT里扫描设备。如果识别出来的设备名称、厂商ID、产品码完全匹配说明EEPROM和从站芯片基本正常。扫描不到从站首先看功能板上两个网口的Link指示灯是否亮。如果不亮查PHY和网络变压器链路如果亮再查EEPROM烧录是否正确。这里有一个容易被忽略的点EEPROM的CRC校验。很多主站在扫描时会校验EEPROM的CRC如果之前用不完整的镜像烧过CRC算不对主站也会拒绝识别。遇到这种情况用主站工具重新生成并烧录完整的EEPROM镜像就好。另外从站在INIT状态下就可以被主站访问EEPROM不需要先进入PREOP这一点在排查时很有用。4.2 状态机切换测试EtherCAT从站状态机分四态INIT、PREOP、SAFEOP、OP。测试时用TwinCAT的ESC诊断窗口手动切换状态观察从站实际状态。正常流程是INIT到PREOPPREOP到SAFEOPSAFEOP到OP。每切一个状态都读一下AL Status寄存器确认当前状态同时检查AL Error寄存器0x0134有没有异常代码。我遇到最多的是PREOP进SAFEOP失败错误码指向SM通道或者PDO映射长度不匹配。这种问题排查思路很直接把XML里配置的SM通道映射和固件初始化SM的代码逐行对比。状态机测试除了正常路径还要测异常路径。比如在OP状态下直接拔掉网线再插回去看从站能不能自动恢复。这个过程最能暴露看门狗配置的问题。EtherCAT从站在OP状态下如果连续几个周期没有收到主站帧SM看门狗就会超时从站自动降级到SAFEOP或INIT。好的设计是从站能在网线恢复后通过主站的重新配置自动回到OP不需要人工干预。如果做不到就要调整看门狗超时时间或者状态切换逻辑。4.3 PDO映射与过程数据通信PDO是EtherCAT周期通信的核心。测试PDO映射时先在XML里配置好RxPDO和TxPDO。比如一个典型伺服轴控制应用RxPDO目标位置4字节、目标速度4字节、控制字2字节TxPDO实际位置4字节、实际速度4字节、状态字2字节从站固件初始化时要按照XML里的SM配置把DPRAM地址映射好。测试PDO通信时主站往RxPDO写一个固定值从站收到后通过TxPDO回传同样的值比较发送和接收是否一致。我建议在从站固件里加一个回环模式把收到的RxPDO数据原样拷贝到TxPDO缓冲区。这样不需要外接任何执行器就能验证整条PDO链路。测试时可先用TwinCAT在线写入一个值观察回传值再写一个递增序列做批量验证。如果数据错位大概率是字节序或DPRAM偏移不对。EtherCAT数据在网络上是大端顺序但DSP内部处理是按小端转换代码写错会出现高低字节交换的经典问题。4.4 CoE邮箱通信测试除了周期PDOEtherCAT从站通常还要支持非周期邮件通信最常用的是CoE协议也就是CANopen over EtherCAT用来读写对象字典。测试CoE时在TwinCAT里对从站对象字典执行SDO上传和下载操作。我们可以在对象字典里自定义几个测试对象比如一个只读对象存DSP固件版本号一个可写对象存测试标志。实测中发现很多从站SDO通信出问题都是邮箱配置不对。邮箱的SM通道必须配置为邮箱协议模式而且要正确声明支持CoE。这个信息在EEPROM里都有体现如果XML或EEPROM里没声明CoE支持TwinCAT会把发送请求标志为不支持。另外SDO块传输对大对象读写性能要求高连续快速读写时注意从站协议栈的邮箱缓冲区不能开得太小否则会丢请求。4.5 分布时钟与同步测试这一步是EtherCAT从站测试里技术含量最高的部分直接关系到多轴同步性能。EtherCAT DC分布式时钟功能让所有从站共享同一个系统时间输出同步信号SYNC0/SYNC1从站据此对齐输出时刻。先让主站启用DC功能读取从站的系统时间、传输延时等参数TwinCAT会自动计算并补偿。然后用示波器同时测主站的周期信号和从站的SYNC0信号观察两个信号的相位差和抖动。对于伺服应用SYNC0信号的抖动一般要控制在1微秒以内才算合格。如果抖动大先查干扰和电源纹波再查FCP32C335中断响应。FCE1100在SYNC0到来时会拉高一个中断引脚通知DSPDSP中断服务函数里的耗时必须足够短且波动小。如果DSP中断里跑了大段计算或者禁中断时间过长抖动会明显变大。实际测试时我会把中断服务函数精简到只拷贝数据和置标志位真正的控制算法在主循环或者高优先级任务里做。另外多个从站级联时要跑一遍全部从站的DC同步测试而不仅仅测单个站这样才能发现传播延时补偿的累计误差。5. 基于FCP32C335的应用功能测试5.1 控制回路闭环跑通测试EtherCAT测试通过以后就要验证FCP32C335这颗DSP真正干活的环节。最基础的测试是搭一个简单的闭环回路主站通过EtherCAT下发目标值DSP用PWM输出一个占空比经过RC低通滤波变成模拟电压再用ADC采样这个电压把实际值通过PDO上传回主站。这个测试完整覆盖了从站读数据、DSP控制、外设输出、ADC采样、数据回传的整条链路。测试时先手动给定一个目标值观察回传的实际值是否稳定到目标附近。如果实际值一直在波动先看PWM频率和滤波器截止频率是否匹配再看ADC采样触发是否和PWM同步。FCP32C335的ADC如果和PWM触发不同步采样时刻落在PWM开关噪声上反馈值会忽高忽低。我在测试时发现过一种情况主站下发目标值后实际值能跟上但有个明显的周期性毛刺。追了一圈发现是FCE1100的SYNC0中断和DSP内部ADC中断优先级冲突导致偶尔一次控制周期被拖长。把ADC中断优先级调低并把关键计算搬进同步中断后毛刺就消失了。这种问题只有闭环测试才能暴露出来。5.2 编码器接口与位置反馈测试如果功能板面向伺服应用FCP32C335的QEP正交编码器接口是必测项。测试时用信号发生器模拟编码器A/B/Z信号也可以接一个真实的增量式编码器手动旋转。DSP通过QEP模块计算位置和速度然后通过EtherCAT的TxPDO上报主站。主站同时下发期望位置比对主站写的值和从站上报值的偏差。这里重点测几个场景正向旋转、反向旋转、经过Z脉冲清零、高速旋转时的计数有没有丢步。有一个容易踩的坑编码器接线顺序反了或者QEP配置的方向极性反了会导致位置值越走越偏。解决方案是在DSP固件里加入方向检测逻辑或者用QEP的计数方向引脚判断并在系统参数里提供极性反转选项。另外如果编码器信号长距离传输注意差分接收和滤波电容的取值电容太大会导致高速时沿变缓丢脉冲。5.3 长时间运行与数据一致性压力测试功能测试全部通过后把板子接到真实主站环境里跑连续运行测试。我习惯跑24小时甚至48小时主站按照项目实际周期下发数据从站持续运行控制算法。数据一致性检查方法是从站固件里维护一个滚动计数器每收到一个PDO周期就加1并通过TxPDO上报。主站侧检测这个计数器是否连续递增一旦发现跳变或重复说明链路上出现了丢帧或重复帧。我测试时有一个常见情况计数器偶尔跳变但网络状态显示一切正常。排查后发现是从站固件里看门狗处理逻辑有Bug在异常情况下重入了初始化流程导致计数器清零。这种偶发问题靠肉眼盯状态很难发现必须靠计数器比对和日志记录才能抓住。压力测试期间还要同时记录板温、电源电流、SYNC0抖动看长时间运行后性能是否漂移。6. 常见问题排查与实测经验6.1 问题速查表现象可能原因排查手段主站扫描不到从站PHY差分线接反、网络变压器虚焊、EEPROM无效检查PHY Link灯、示波器测MII/RMII信号、重新烧录EEPROM从站卡在PREOP进不了SAFEOPSM通道未配置、PDO映射长度不匹配、邮箱配置错误对比XML和固件配置、查看AL Error寄存器、抓EtherCAT帧分析OP状态但PDO数据不刷新DC同步未启用、看门狗配置错误、SPI读写冲突检查DC参数、示波器看SYNC0、逻辑分析仪抓SPISYNC0抖动大电源纹波、DSP中断响应太慢、FCE1100中断被屏蔽示波器测纹波、精简中断函数、调整中断优先级SDO读写超时邮箱SM配置错误、对象字典索引错误、块传输缓冲不足用TwinCAT在线扫描对象字典、增大邮箱缓冲我自己实测下来出现频率最高的其实是第一行和第三行。PHY电路问题往往在原理图阶段就有隐患比如差分线不按100欧姆阻抗布线、网络变压器中心抽头处理不对。功能板测试流程里一定要包含一次PHY信号眼图测试或者至少是MII/RMII时钟信号观察不要偷懒。6.2 排查技巧和避坑心得做EtherCAT从站测试心态要稳。EtherCAT链路层的问题经常是间接原因造成的不是非黑即白。我总结三个技巧第一从站侧所有状态变化都要打日志。FCE1100的AL状态、错误码、SPI通信失败次数都记录下来通过调试器串口输出。很多偶发问题只有日志才能还原现场。第二用抓包工具保留“犯罪现场”。当从站异常时立刻停止主站刷新用分析仪把最后一段EtherCAT帧存下来。分析帧里主站请求了什么、从站回了什么很多问题一眼就能看出来。第三最小化复现。我遇到过一个问题功能板一切正常但装了底板后从站偶发掉线。开始怀疑底板干扰后来把外壳装上才稳定。最后排查发现是底板没有良好的接地EtherCAT网口的共模干扰过大。这种系统性干扰问题靠逐层排除法能省很多时间。6.3 关于国产芯片资料的心得国产从站芯片和DSP配套资料相比国际大厂可能会零散一点但这两年已经好很多了。FCE1100的寄存器说明和示例代码基本能覆盖开发需求FCP32C335的外设库也兼容主流DSP开发习惯。如果遇到手册没讲清楚的地方我的经验是直接看配套的从站协议栈源码它比手册更接近真实行为。比如FCE1100的EEPROM读写在协议栈里会有完整示例比手册里的时序图直观得多。另外厂商FAE的支持速度也很快碰到疑难杂症不要不好意思问。7. 测试记录与判定标准7.1 测试项与通过标准建议测试流程要能落地必须把每一项的判定标准量化。我常用的测试项清单如下测试阶段测试项通过标准上电最小系统电源电压/纹波各路电压偏差小于5%纹波小于50mV上电最小系统复位时序满足芯片手册时序要求示波器截图存档双芯通信SPI寄存器读写读AL Status返回值正确连续读写1000次无错误EtherCAT协议从站识别主站识别名称/厂商ID/产品码与XML一致EtherCAT协议状态机切换四态切换无报错异常恢复时间小于1秒EtherCAT协议PDO回环连续100万个周期数据无错位、无丢帧EtherCAT协议DC同步SYNC0抖动小于1微秒长时间漂移小于5微秒应用功能闭环控制实际值稳态误差小于设定阈值动态响应符合预期应用功能编码器反馈位置计数无丢步正反向对称可靠性24小时压力滚动计数器无跳变板温在允许范围内这个表你可以按自己项目调整但原则是一定要量化和可复核。比如“工作正常”这种话不能当标准“连续100万周期无错误”才是标准。7.2 把测试流程固化到产线研发阶段的测试流程跑顺了不代表产线就能直接照搬。产线测试追求速度快、操作门槛低需要把测试步骤固化到自动化工具里。我建议用Python脚本通过TwinCAT ADS接口自动执行测试读取从站状态、写PDO数据、记录结果到Excel或者数据库。产线工人只需要把板子接上电源和网线点击“开始测试”几分钟后屏幕上显示PASS或者FAIL。这样既提高了效率又避免了人工操作的误判。固件里也要预留产线测试模式。比如通过CoE写入一个测试使能对象从站自动执行自检并返回结果。这样产线不需要理解EtherCAT协议细节只需要看结果。最后再分享一个个人经验测试流程本身也要持续迭代。每发现一个新问题就把复现步骤和排查方法补充到测试文档里形成问题库。这样同一个坑不会踩第二次团队里的新工程师也能快速上手。我这套FCE1100和FCP32C335功能板的测试流程就是在一个个具体问题里打磨出来的过程很折腾但跑顺之后的稳定感值得。
