最近手头拿到一块国产化运动控制方案的核心板板上同时集成了EtherCAT从站控制器FCE1100和国产DSP芯片FCP32C335。这类组合在当前工控国产化替代浪潮里非常典型——从站芯片负责实时通信DSP负责运算和控制算法二者配合才能撑起一套完整的伺服或IO控制方案。不过芯片是新的参考设计是有的真正到了自己搭测试流程的时候坑还是一点都不少。这篇文章我把整个功能板的测试流程梳理一遍从硬件准备、上电时序、从站配置到DSP固件烧录、通信联调、异常排查全程记录我实际跑过的步骤和踩过的坑。FCE1100这颗芯片在国产EtherCAT从站方案里算比较有代表性的FCP32C335也是目前在工业控制领域用得越来越多的国产DSP这两个组合的测试经验基本可以平移参考到同类的国产化板卡验证工作中。1. 功能板整体测试思路与方案选型1.1 为什么选FCE1100加FCP32C335这套组合先说结论这套组合是目前国产化率比较高的EtherCAT从站控制方案选它来做功能板测试核心解决的是两个问题一是替代进口从站芯片比如ET1100、ET1200带来的供应链风险和成本问题二是替代进口DSP/MCU比如TMS320F28335在核心控制算法上的国产化需求。FCE1100作为EtherCAT从站控制器ESC主要负责的事情很纯粹把主站比如倍福TwinCAT、欧姆龙NJ、汇川AM系列或者Linux下的EtherCAT主站发过来的报文解析出来通过本地数据接口通常是并行总线或者SPI把数据交给DSP同时把DSP反馈的数据打包发回主站。这颗芯片对标的就是ET1100的定位所以从站功能的寄存器定义、同步管理通道SM、FMMU这些概念跟标准EtherCAT协议一致测试的时候思路可以延续。FCP32C335则是一颗国产的浮点DSP跟TI C2000系列的F28335管脚和指令集兼容度比较高。在这个方案里它干的是脏活累活——电流环、速度环、位置环的控制运算编码器接口的数据处理IO逻辑的实时响应以及和FCE1100之间的数据交换。这两颗芯片之间怎么连接直接决定了功能板测试的内容和流程。我手上这块板子的设计是FCE1100作为从站芯片挂在EtherCAT总线上DSP通过16位并行总线和中断信号跟FCE1100通信。这个架构的好处是实时性有保障报文到达FCE1100之后DSP可以立刻通过中断感知并取走数据延迟非常低。1.2 功能板测试流程的分层设计面对这样一块从零开始验证的功能板我习惯把测试流程分成四个层次来推进每一层都有明确的目标和判定标准避免一上来就陷入复杂联调导致问题难以定位。第一层是硬件基础测试验证电源、时钟、复位、JTAG链路是否正常。这一层如果不过关后面所有工作都是空中楼阁。第二层是DSP最小系统验证包括GPIO翻转、串口打印、定时器中断这些基本功能。第三层是FCE1100从站功能验证包括EEPROM配置、从站信息读取、SM通道通信。第四层才是联调和应用测试把DSP的控制算法跑起来验证整个系统的实时性和功能完整性。这个分层思路特别重要。我曾经见过有人一上来就直接跑伺服电机结果转速不稳查了半天发现是电源纹波太大导致DSP复位这种问题如果按分层思路来测在第一步就能暴露出来。1.3 测试环境搭建的整体规划测试环境的搭建直接决定测试效率和结果可信度。我这边常用的配置是一台装有TwinCAT 3的工控机作为EtherCAT主站一个24V开关电源给功能板供电一个J-Link仿真器用于DSP调试和烧录再加上示波器和万用表用于硬件信号验证。主站和从站之间的物理层用的是标准的RJ45网线和EtherCAT专用网口。有一点要特别提醒EtherCAT的网口物理上是标准以太网口但是千万不要用它去接普通的交换机或路由器EtherCAT报文是实时以太网协议普通交换机处理不了会导致通信失败。TwinCAT识别从站靠的是从站的EEPROM里面烧录的SII信息Slave Information Interface所以FCE1100的EEPROM烧录是整个测试流程里非常靠前的一个关键步骤后面会详细说。2. FCE1100从站芯片核心要点与配置解析2.1 FCE1100的寄存器体系和数据交互方式FCE1100的内部寄存器体系和标准EtherCAT从站控制器是一致的核心包括ALApplication Layer控制寄存器、DLData Link Layer控制寄存器、SMSync Manager同步管理通道寄存器、FMMUFieldbus Memory Management Unit寄存器、以及ESC内部的内存映射空间。如果之前接触过ET1100上手FCE1100会非常快因为寄存器地址和函数定义基本是兼容的。如果是第一次接触EtherCAT从站开发我建议先用SSC工具EtherCAT Slave Stack Code生成一套从站协议栈代码跑通了再自己动手写精简版。FCE1100和DSP之间的数据交互通常采用共享内存的方式也就是ESC内部有一块DPRAMDSP可以直接读写。SM0、SM1用于过程数据输出和输入SM2、SM3通常用于邮箱通信非周期性数据比如参数读写、SDO服务。在实际测试中我会先验证SM配置是否生效再用简单的字节翻转来验证过程数据通道是否打通。2.2 从站EEPROM配置与SII信息烧录EEPROM里存着从站的SII信息包括厂商ID、产品码、版本号、设备名称、SM通道配置、FMMU配置、PDO映射信息等。主站扫描总线的时候就是通过读这些信息来识别从站设备的如果EEPROM是空的或者内容不对TwinCAT里就会显示unknown device或者扫描不到设备。烧录EEPROM可以用几种方式我比较常用的是通过TwinCAT的ESC工具直接在线烧写前提是FCE1100已经能通过EtherCAT链路被主站访问到。另一种是通过SSC工具生成EEPROM镜像然后用烧录器写进去这个方式适合量产阶段。SII信息里有几个地方特别容易出错。一个是PDO映射必须在SII里就定义好过程数据的内容和格式否则主站分配的地址和数据长度对不上通信虽然能建立但数据全是乱的。另一个是SM通道的配置过程数据用哪几个SM通道方向是什么必须在SII里写清楚并和DSP侧的程序保持一致。提示EEPROM烧录之前一定要先读一遍原有内容备份。芯片出厂时可能带默认配置或者全FF烧录后如果发现主站识别异常恢复备份是排除问题的第一手段。2.3 FCE1100与DSP之间的接口时序验证FCE1100和DSP之间的并行接口是整块板子数据通路的咽喉时序不对会导致数据错位或者丢数据。验证这个接口我通常会在DSP侧写一个简单的读写测试程序往特定的ESC地址空间写入一组特征值比如0xAA55、0x5AA5交替然后读回来比对。要注意的是FCE1100的并行总线访问时序参数——地址建立时间、数据保持时间、片选有效时间——都需要和DSP的外部接口XINTF如果有的话参数匹配。如果DSP访问速度太快可能读回的数据不稳定太慢则影响实时性。我在实际测试中曾经遇到过DSP配置了错误的等待周期数导致读写FCE1100寄存器偶尔出错排查了很久最后用示波器抓了总线的时序波形才定位到问题。如果板子上用的是SPI接口连接FCE1100也要特别注意SPI的模式和速率匹配尤其是CPOL和CPHA必须和FCE1100的要求一致。这一点不同批次芯片可能还有差异务必以官方数据手册和参考代码为准。3. FCP32C335 DSP功能验证与固件准备3.1 拿到样片后的第一步最小系统验证FCP32C335这颗DSP因为跟TMS320F28335兼容性比较好所以调试方式和开发环境也沿用了TI的CCSCode Composer Studio。最开始的测试我建议先不要接任何外设就做一个最小系统验证上电之后看内核时钟是否正常、JTAG能否连接到CPU、GPIO能不能翻转、串口能不能打印。这里面最容易出问题的也是我在这颗芯片上踩过的一个比较大的坑就是电源时序。DSP的IO电压3.3V和内核电压1.8V左右如果上电顺序不对轻则无法启动重则损坏芯片。核心理念是内核电压上电不能晚于IO电压太多具体顺序要严格按数据手册来。测的时候我习惯用示波器双通道同时抓两路电源的上升沿确认时序符合要求后再进行后续测试。JTAG连接是另一个高频问题点。F28335兼容的DSP一般是14针JTAG接口如果板子上走线比较长还需要注意仿真器的线缆质量和长度以及目标板是否需要JTAG信号缓冲。我在调试另一块板子时遇到过仿真器能连上但是一执行就跑飞的情况最后发现是TRST引脚被下拉电阻影响了复位时序去掉就好了。3.2 常见坑DSP固化程序后必须接JTAG才能启动这是我在搜索热词里看到不少人在问的问题也是DSP开发里一个非常经典的现象。DSP固化程序之后必须接JTAG才能启动本质上不是JTAG在起作用而是程序的启动引导Boot过程没有按预期执行。FCP32C335和F28335一样有多个启动模式引脚Boot Mode引脚芯片复位后会根据这些引脚的电平决定从哪里启动——是从Flash启动还是从SCI、SPI、并行IO等外设引导。如果Boot Mode引脚配置不对芯片默认可能走的是其他引导模式根本不会去读Flash里的程序自然就“没法启动”。而接上JTAG之后仿真器会把CPU halt住然后用户手动加载程序或者重新指定运行地址看起来就像“接上JTAG才能运行”。解决这个问题的方法很直接检查Boot Mode引脚的上下拉配置。从Flash启动对应的引脚电平组合在数据手册里有明确说明把引脚配置到正确电平后断电重新上电程序就能独立运行了。另外还有一个容易被忽略的点就是固化的时候要把程序烧到Flash的正确地址并且要配置好代码的链接地址CMD文件。有些代码在RAM里跑得好好的但烧进Flash之后一上电就死机往往是因为中断向量表、跳转地址这些在Flash里的重映射没有处理好。3.3 DSP侧EtherCAT协议栈的集成思路DSP和FCE1100配合实现EtherCAT从站协议栈代码可以放在DSP上跑。常用的做法是用SSC工具生成针对FCE1100的从站代码然后移植到CCS工程里。SSC工具生成代码的时候可以选择应用层接口类型有的工程师习惯用通用IO方式有的用邮箱方式。我建议一开始先用最简单的过程数据方式把通路跑通——主站下发一个变量DSP收到后再回传一个变量TwinCAT里能实时看到变化就算基本打通了。DSP端的协议栈要注意一个优化点中断响应时间。FCE1100在收到主站的过程数据帧之后会产生一个SYNC中断或者SM事件中断给DSPDSP响应这个中断的速度直接决定了从站的处理延迟。实际测试中我会把中断服务函数做得尽量精简只做数据搬运和标志位置位重计算全部丢到主循环或者低优先级任务里。还可以用__attribute__((ramfunc))把关键的中断处理函数放到RAM里执行避免Flash等待周期带来的不确定延迟。注意DSP访问FCE1100共享内存时如果使用并行总线建议加上等待周期或者使用DSP的XREADY信号确保访问时序稳定。这个细节在低速调试时不易暴露但在高速运行时就是致命问题。4. 实操测试步骤与联调验证全记录4.1 硬件上电与基础信号测试拿到功能板之后我先用万用表测了一遍电源对地阻抗确认没有短路才上电。上电后依次检查各电源轨电压幅值、复位信号的电平、时钟输出波形。FCE1100的时钟一般是由板上的晶振提供或者是DSP输出的时钟经过分频/倍频后供给。用示波器看一下时钟波形是否干净有没有毛刺或幅值不足这类问题会影响EtherCAT的数据收发质量。晶振起振慢或者幅度不够会出现从站偶尔被主站踢掉线的现象排查起来很费劲所以基础信号测试这一步千万别跳。我们这块板子上电后先用示波器确认了3.3V、1.8V、基准电压都没有问题然后通过J-Link连接DSP读到了CPU ID确认DSP核心工作正常。接着点灯测试GPIO翻转方波用示波器看到了50%占空比最小系统就确认OK了。4.2 EtherCAT从站扫描与EEPROM配置实操DSP最小系统确认后开始进行FCE1100的从站验证。先用网线把功能板接到装有TwinCAT的工控机网口上注意不要接错口——EtherCAT从站通常有两个网口IN和OUT接IN即可另一个口用于链式级联下一站。在TwinCAT的扫描设备界面点击扫描后如果有未知设备出现说明FCE1100的链路层已经工作了。这个时候EEPROM可能是空的或者内容不对我用TwinCAT的ESC工具在线对EEPROM进行了烧写。烧写前先在工具里配置好SII信息包括从站名称、厂商ID、产品码等然后点击写入。实测烧写时间大概几秒钟完成后断电重新上电再次扫描就能看到设备的正确型号了。这个时候TwinCAT里会显示从站的PDO信息如果PDO映射也正确就可以尝试把从站切换到OP状态了。4.3 过程数据通信验证从站进入OP状态后我在TwinCAT里创建了过程数据变量下发了一个递增的计数值然后在DSP侧的协议栈代码里把收到的值加1再回传。通过TwinCAT的在线监控可以看到回传值等于下发值加1说明过程数据通道完全打通。这里有一个细节PDO通信正常的前提是DSP侧的PDO映射和EEPROM里配置的PDO映射必须完全一致包括变量类型、长度、顺序。如果不一致主站认为的PDO布局和从站实际的数据布局就对不上读到的数据就会错位。测试的时候如果发现数据对不上优先检查两侧的PDO配置是否一致。4.4 邮箱通信与SDO参数读写验证过程数据通了之后我继续验证邮箱通信。EtherCAT的邮箱通信用于传输非周期数据比如SDO参数读写。在主站侧TwinCAT里可以直接用Coe对象字典的在线写功能给从站写入一个参数比如某个控制增益然后读回来确认值是否正确。邮箱通信涉及SM2/SM3或者SM0/SM1里预留的邮箱通道以及FIFO机制。调试邮箱通信时要特别注意数据长度字段和校验字节是否正确。我遇到过从站能收到邮箱数据但主站一直报邮箱超时的情况最后排查下来是邮箱数据长度设置错误导致从站回复的邮箱头里长度字段对不上。4.5 整机联调与实时性验证单站功能验证完成后我又在网络上挂了一个真实的IO模块作为第二站组成主站到两个从站的小型拓扑。这时候重点验证的是链式级联是否正常、两个站能不能同时进入OP状态、过程数据是否同步更新。实时性方面我用TwinCAT的Scope功能录了主站下发到从站并返回的周期时间。FCE1100的处理延迟本身很低主要可变因素是DSP的中断响应和并行总线访问时间。实测下来在我们这块板上从报文到达FCE1100到DSP完成数据处理再返回整个往返时间控制在一个通信周期内我们跑的是1ms周期是完全没有问题的。如果你手头的伺服控制要求更高比如125us甚至62.5us的同步周期就要特别注意DSP中断服务函数的耗时和代码执行的确定性。可以把中断服务函数里所有操作都放到RAM里执行同时把PDO数据处理程序模块化减少分支跳转能提升不少稳定性。5. 测试过程中遇到的典型问题与排查方法5.1 从站扫描不到TwinCAT显示无设备这个现象排查思路相对固定。先用TwinCAT的网络适配器诊断功能确认主站网卡是否识别到EtherCAT链路再用示波器测量FCE1100的链路LED或者寄存器状态看Link是否建立接着确认FCE1100的EEPROM是否烧录了有效的SII信息没有SII的话主站可能识别为unknown device。在实际测试中我们还遇到过一种情况就是从站的第二个网口OUT悬空时某些主站软件会因为这个口没有数据返回而扫描异常。排查时可以先用单站短链的方式即只接IN口看能否扫描到。5.2 DSP程序固化后无法独立启动前面详细说过Boot Mode引脚配置是最大的嫌疑点。建议在原理图设计阶段就把Boot Mode引脚用排针引出方便测试时切换不同启动模式来排查。另外一个排查点是上电复位电路。如果复位信号不够宽或者有毛刺DSP可能在上电瞬间复位不完全导致启动乱跳。用示波器抓复位引脚的波形确保复位低电平持续时间足够长通常需要几十毫秒而且高电平要稳定到3.3V没有跌落。5.3 通信建立后偶发掉线或反馈数据跳动这类问题通常指向几个方向电源纹波大导致芯片工作不稳定、网线或连接器接触不良、并行总线时序裕量不足、DSP中断响应抖动。我曾经排查过一个间歇性掉线的问题最后用示波器持续监控发现是板子上一颗DC-DC电源芯片的开关频率和EtherCAT通信频率产生了拍频干扰导致FCE1100的供电在通信瞬间产生跌落。后来在电源输出端增加了一颗大容量的钽电容和去耦电容掉线问题就消失了。5.4 PDO数据正常但SDO读写超时PDO数据正常说明基础链路和SM配置是通的SDO超时通常集中在邮箱通道的配置上。比如SM2/SM3的缓冲区大小、邮箱数据最大长度、FIFO读写指针是否正确以及从站协议栈的邮箱数据处理是否进入了正确的状态机。还有一个容易忽略的点是CoE对象字典的索引和子索引定义。主站下发的SDO索引从站的应用层代码必须支持不然协议栈会回复异常或者直接忽略。调试时可以在DSP侧加断点或者串口打印判断邮箱中断是否触发、SDO数据是否进入了应用层处理函数。6. 后续扩展思路与国产化方案展望这块功能板测试通过之后后续的扩展方向其实很清晰。一方面可以在FCP32C335上跑完整的伺服控制算法通过EtherCAT闭环控制电机把位置环、速度环、电流环的性能都压测一遍另一方面可以加入国产的编码器接口芯片或者隔离通信方案让整个控制链路的国产化率进一步提升。FCE1100目前在国内的EtherCAT从站方案里已经比较成熟配套的SSC代码、参考设计和技术支持都比较完善。FCP32C335的生态也在逐渐铺开开发工具链上CCS可以兼容底层的库也在逐步完善。如果你们团队正在做国产化控制器的选型或者替代验证这套组合可以认真评估一下。最后再分享一个我自己测试过程中的习惯每一轮测试都要留下记录包括固件版本、SII配置、主站版本、测试内容和结果。这个习惯在项目早期看似费时间但到了后面联调和排障阶段能省下大量重复排查的时间。如果你也在做类似的国产EtherCAT从站或者DSP功能板测试欢迎交流测试过程中遇到的问题尤其是FCE1100和FCP32C335这两个芯片配合使用时的细节。每个板子的硬件设计都不一样别人的经验不能完全套用但排查思路和数据交互的底层逻辑是通用的希望对你有帮助。