做EtherCAT从站开发有些年头了手里的项目从早期的专用ASIC方案一路做到MCU从站控制器组合。这次把一套基于其他MCU平台的EtherCAT从站代码迁移到STM32F103LAN9252组合上原本以为只是换个编译器、改改寄存器映射的事结果硬生生被5个硬件层面的问题按在地上摩擦了一个多月。这篇文章把迁移过程中踩过的坑、排查思路和最终方案完整记录下来给后面走这条路的朋友当个参考。这套方案的核心链路很简单STM32F103作为应用处理器AP通过SPI接口与LAN9252EtherCAT从站控制器ESC通信LAN9252负责处理EtherCAT协议栈和实时以太网通信。说句公道话F103虽然在2024年已经算老将但它有价格低、生态成熟、CubeMX一键生成初始化代码这些优势在成本敏感的从站设备里依然是出货量最大的选择之一。而LAN9252则是Microchip原SMSC的经典ESC芯片自带两个以太网PHY口支持DC分布式时钟内部有8KB的DPRAM映射寄存器空间外部MCU通过SPI或并行总线就能访问。这篇文章适合谁看准备把现有从站代码从F407/H7或者其他MCU平台迁移到F103的工程师以及正准备用STM32F103最小系统搭配LAN9252做EtherCAT从站的新手。我会把每个坑的故障现象、根因分析、解决方案和实测验证方法都讲透也会给出可以“抄作业”的代码片段和检查清单。1. 为什么把EtherCAT从站迁移到STM32F1031.1 方案背景与选型考量原来这套从站代码跑在一颗Cortex-M7内核的高端MCU上功能验证全部通过量产时却碰上了芯片缺货和成本压力。一颗高端MCU的钱足够买3颗F103再加上老板一句“原理图改动尽量小”就把迁移目标锁定在了STM32F103C8T6这颗经典芯片上。F103的资源情况要先盘一下72MHz主频、64KB Flash、20KB SRAM片上外设包括3个USART、2个SPI其中SPI1挂在APB2最高36MHzSPI2挂在APB1最高18MHz、1个CAN、1个USB从机、2个12位DAC、多个定时器。对于典型的EtherCAT数字量从站来说这些资源是够用的——协议栈状态机、PDO映射、应用逻辑加起来Flash占用通常能控制在30KB以内RAM占用也能压缩到10KB以下。但迁移不是简单的重新编译最关键的问题是原来跑在Cortex-M7上的代码对SPI速率、中断响应延迟、DMA缓冲区的假设在F103上全部要重新验证。最典型的就是SPI1最大36MHz、SPI2最大18MHz的时钟上限和F407上动辄42MHz的SPI时钟根本不是一个量级代码里如果写死了SPI分频系数迁移后通信时序必然出问题。后面会详细讲。1.2 LAN9252与STM32F103的典型连接我采用的连接拓扑是业界最常见的SPI从站模式引脚分配如下SPI1_SCKPA5连接LAN9252的SCLKSPI1_MISOPA6连接LAN9252的MISOSPI1_MOSIPA7连接LAN9252的MOSISPI1_NSSPA4连接LAN9252的CSPB0连接LAN9252的IRQ中断输出PB1连接LAN9252的RST复位输出这里有个容易踩的细节LAN9252的IRQ引脚是开漏输出外部必须接上拉电阻。而且IRQ是低电平有效如果PCB板上忘了加上拉或者上拉电阻值取得太大比如100kΩ在高噪声环境下会频繁误触发。我把IRQ放在PB0而不是PA11/PA12就是为了避开F103上这两个引脚的USB复用冲突问题这个在坑三里会细说。供电方面LAN9252需要3.3V供电但它的PHY模拟部分AVDD和数字部分DVDD要分开供电至少要用磁珠做单点隔离。F103本身也是3.3V供电两者可以共用主电源但LAN9252的AVDD电源引脚附近要加足够容量的去耦电容推荐用4.7μF钽电容并联100nF陶瓷电容靠近引脚放置。2. 坑一SPI接口参数照搬通信时好时坏2.1 现象描述寄存器读到0xFFFF代码迁移完成后的第一次通电测试读取LAN9252的BYTE_ORDER寄存器地址0x0000魔数应该返回0x87654321的实际字节序关系。结果串口调试打印出来的值要么是0xFFFFFFFF要么是随机跳变的数值。用逻辑分析仪抓取SPI波形发现数据线上确实有波形但SCLK频率似乎偏高MISO上的返回数据根本没有有效响应。一开始还怀疑是LAN9252没正常启动反复检查复位引脚电平甚至怀疑芯片虚焊重新拖焊了一遍问题依旧。后来静下心来翻数据手册才算找到真正的方向。2.2 根因分析时钟极性与分频设置问题出在两个地方SPI时钟极性和时钟分频。先说极性。LAN9252的数据手册明确推荐SPI工作模式为Mode 0CPOL0CPHA0即SCLK空闲时为低电平数据在第一个跳变沿上升沿采样。原代码是为另一颗主控芯片写的那颗芯片的SPI控制器默认配置是Mode 1CPOL0CPHA1也就是数据在第二个边沿采样。这个差异直接导致通信时序不匹配LAN9252根本收不到有效命令自然也不会正确返回数据。再说分频。原平台SPI时钟可以跑到40MHz以上代码里SPI分频系数写的是2分频。迁移到F103后我一开始用的是SPI2挂在APB1APB1时钟是36MHz2分频后SPI时钟为18MHz虽然理论上低于LAN9252的20MHz上限但18MHz已经非常逼近极限加上走线寄生电容和板上噪声实际的信号质量已经很差了。更要命的是APB1时钟在F103上默认是HCLK的2分频也就是36MHz如果代码里不小心把APB1配置错误SPI2的输入时钟就只有18MHz2分频后实际SPI时钟只有9MHz反过来又会拖慢通信速率。2.3 解决方案与验证方法这一步的解决思路是先把模式改对再压低速率验证稳定性最后逐步提频。SPI初始化代码改成下面这样SPI_HandleTypeDef hspi1; hspi1.Instance SPI1; hspi1.Init.Mode SPI_MODE_MASTER; hspi1.Init.Direction SPI_DIRECTION_2LINES; hspi1.Init.DataSize SPI_DATASIZE_16BIT; hspi1.Init.CLKPolarity SPI_POLARITY_LOW; // CPOL0, Mode 0 hspi1.Init.CLKPhase SPI_PHASE_1EDGE; // CPHA0, Mode 0 hspi1.Init.NSS SPI_NSS_SOFT; hspi1.Init.BaudRatePrescaler SPI_BAUDRATEPRESCALER_16; // 72MHz/16 4.5MHz hspi1.Init.FirstBit SPI_FIRSTBIT_MSB; HAL_SPI_Init(hspi1);注意几个细节LAN9252的SPI接口支持8位和16位两种数据宽度但访问内部寄存器时命令字1字节读/写命令1字节地址和数据字组合起来很多现成驱动代码喜欢用16位模式一次性发送地址数据。我这里也采用16位模式但必须确认LAN9252的地址是字节地址还是字地址这直接影响到CS拉低期间传输的字节数。配置完成后先用4.5MHz的保守速率跑起来读取BYTE_ORDER寄存器验证通信正常再逐步提高SPI时钟。实测在我这块板子上SPI1APB272MHz4分频即18MHz时工作稳定2分频即36MHz时偶尔会出现CRC错误LAN9252的SPI协议自带校验可以通过状态寄存器观察到所以最终留在了18MHz。这里总结一个排查顺序先查SPI模式CPOL/CPHA再查分频后的实际时钟频率最后用逻辑分析仪看CS、SCLK、MOSI、MISO四条线的时序关系。如果手上没有逻辑分析仪可以写一个简单的回环测试程序把MOSI和MISO短接用SPI发送一串已知数据看接收端能否原样收到。这个办法能快速排除SPI控制器本身的问题。3. 坑二复位时序带动上电顺序失控3.1 现象描述必须手动复位一次才能工作SPI通信参数修正之后通信已经正常了但出现了一个更隐蔽的毛病每次冷启动断电再上电从站都起不来主站扫描不到设备。但只要我用手按一下板子上的复位按键同时复位F103和LAN9252设备马上就能正常工作。这个问题在开发阶段还能忍一旦设备部署到现场没有人会专门去按复位键。而且这种“上电失败、手动复位就正常”的现象在从站设备里很有代表性——它不是某个寄存器的配置问题而是硬件复位时序不满足芯片要求。3.2 根因分析LAN9252的上电初始化流程翻看LAN9252的数据手册上电后内部要完成一系列初始化动作PHY上电、内部PLL锁定、EtherCAT状态机复位、DPRAM初始化。这些动作需要的时间保守估计在10ms以上。手册上明确写了RST引脚拉高后至少要等t_ready时间我实测约10~20ms之后外部MCU才能开始通过SPI访问寄存器。问题在于迁移后的代码是怎么写的。原来的初始化序列是配置F103的GPIO把RST拉低执行一些本地外设的初始化耗时可能只有1~2ms然后把RST拉高紧接着就去读LAN9252的寄存器。这个时间窗口远小于LAN9252完成内部初始化所需的时间导致SPI访问到的都是复位状态下的默认值或者全0xFF从站自然无法进入OP状态。更隐蔽的是F103的GPIO默认状态。STM32F103在芯片复位后所有GPIO都处于浮空输入状态。如果RST引脚连接的GPIO在系统时钟启动前出现一个短暂的高电平毛刺来自电源上电顺序或者JTAG/SWD调试器的复位行为LAN9252可能会在这个错误的时间点退出复位加上后续用户代码又把它拉低再拉高整个时序就更乱了。3.3 解决方案GPIO复位流程与RC兜底我在代码里专门写了一个LAN9252的硬件复位函数放在所有SPI初始化之前执行并且把时序放宽void LAN9252_Reset(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); // RST引脚配置为推挽输出 GPIO_InitStruct.Pin GPIO_PIN_1; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOB, GPIO_InitStruct); // 拉低复位引脚保持至少50ms HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_RESET); HAL_Delay(50); // 拉高复位引脚等待芯片完成内部初始化 HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_SET); HAL_Delay(50); // 等待CRBCommand Register Busy位清除 // 可以读取LAN9252的BYTE_ORDER寄存器验证 uint32_t timeout 10000; while (timeout--) { // SPI读取寄存器若读取到魔数则初始化成功 if (SPI_ReadRegister(0x0000) 0x87654321) break; HAL_Delay(1); } }另外我在硬件设计上加了一道保险在LAN9252的RST引脚上加了一个简单的RC延时电路10kΩ上拉到3.3V1μF电容对地。这样即使F103的程序运行出现问题LAN9252也能在上电后自动完成复位时序不至于因为软件死机导致从站一直无法工作。RC时间常数大约10ms配合软件50ms的拉低延时双保险。软件复位流程的关键点是必须先初始化SPI再执行复位函数。顺序反了的话SPI读寄存器的操作没有硬件基础验证循环会一直超时。如果调试中遇到复位后SPI通信仍然失败优先检查LAN9252的电源是否起来、晶振是否起振、RST引脚电平是否符合预期这三点是芯片正常工作的基础。4. 坑三中断引脚选错触发像抽风4.1 现象描述IRQ不进入或误触发初始化、复位时序都搞定了EtherCAT状态机也能从INIT走到PREOP但运行一段时间后从站会突然失联或者主站发来的帧从站响应变慢。把调试信息打开发现LAN9252的中断请求引脚IRQ根本没有按照预期触发STM32F103的外部中断。最初的设计把LAN9252的IRQ接在了F103的PA11上原因很简单原来的设计平台有一路空闲GPIO正好是PA11想着引脚编号一致就不用改原理图了。结果问题接踵而至——PA11这个引脚在F103上不是省油的灯它同时是USB的D-引脚、CAN1的RX引脚甚至在部分封装上还涉及到BOOT配置相关的复用逻辑。如果初始化代码里使能了USB外设的时钟PA11的控制权会被USB控制器抢走GPIO外部中断配置根本不起作用。即使没有使能USBPA11作为IRQ输入时如果内部上拉没有开而LAN9252的IRQ输出是开漏结构高电平状态会处于不确定状态导致频繁的误触发。4.2 根因分析PA11/PA12的特殊复用与EXTI映射顺着这个现象深入查资料发现问题的根源不止一个。第一是PA11/PA12的复用优先级。在STM32F103参考手册的GPIO复用功能表中PA11/PA12的默认复用功能是USB如果RCC_APB1ENR中的USBDEN位被置1即使代码里没有主动调用USB相关的API引脚的控制权也可能会转移到USB外设。而很多从站代码在初始化时会顺手开启所有外设时钟其中就包括USB时钟。第二是EXTI中断线路映射。F103的外部中断EXTI0~EXTI15分别对应GPIOx的Pin0~Pin15同一编号的引脚只能有一个端口映射到EXTI线。如果代码里同时配置了PA11和PB11的EXTI中断后配置的会覆盖前者。这在迁移代码时很容易被忽略——原平台可能用的是一个支持多条EXTI线同时映射到不同引脚的MCU迁移到F103后这个特性不存在了。第三是IRQ引脚的电平极性。LAN9252的IRQ引脚内部是开漏输出低电平有效。外部必须接上拉电阻或者依赖MCU内部上拉。PA11在F103上默认是浮空输入内部上拉需要手动使能。我在排查时用示波器量了PA11的静态电平发现它浮在1.2V左右这个既不是高电平也不是低电平的不确定状态正好说明上拉电阻缺失。4.3 解决方案引脚选型与EXTI配置模板这次踩坑之后我直接把IRQ引脚从PA11换到了PB0彻底避开USB和CAN的复用冲突区。PB0是纯粹的GPIO没有任何外设复用冲突问题。修改后的EXTI配置如下static void EXTI_Init(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); __HAL_RCC_SYSCFG_CLK_ENABLE(); // IRQ引脚PB0上拉输入 GPIO_InitStruct.Pin GPIO_PIN_0; GPIO_InitStruct.Mode GPIO_MODE_IT_FALLING; GPIO_InitStruct.Pull GPIO_PULLUP; HAL_GPIO_Init(GPIOB, GPIO_InitStruct); // 中断优先级配置 HAL_NVIC_SetPriority(EXTI0_IRQn, 1, 0); HAL_NVIC_EnableIRQ(EXTI0_IRQn); } void EXTI0_IRQHandler(void) { HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_0); } void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin GPIO_PIN_0) { // 清中断标志读取LAN9252中断状态寄存器处理对应事件 uint16_t intStatus SPI_ReadRegister(LAN9252_IRQ_STATUS); // 根据intStatus处理相应事件 } }这里要特别注意F103的外部中断优先级不要设置得太高。LAN9252的IRQ频率在高速EtherCAT通信场景下可能达到几十kHz如果中断优先级高于SPI的DMA传输完成中断就会出现中断嵌套问题导致SPI数据错乱。我实测把EXTI0设置为优先级1中等偏低SPI和DMA中断设置为优先级0最高这样LAN9252的中断请求不会打断正在进行的SPI传输。除了选引脚还要检查代码中是否无意开启过USB外设时钟。在SystemInit或者外设初始化代码中把RCC-APB1ENR的USBDEN位清零避免PA11/PA12被USB控制器抢走。即使不用PA11养成这个习惯也能减少后续排查的麻烦。5. 坑四时钟源不一致从站同步漂移5.1 现象描述DC同步误差越来越大从站设备在实验室单机调试时一切正常但接入真实的EtherCAT主站网络开启分布式时钟DC功能后同步误差越来越大从站设备的数字量输出会周期性抖动最终被主站判定为同步失败而强制下线。这个问题最初怀疑是LAN9252的中断响应太慢于是加大中断优先级、优化SPI传输但收效甚微。后来才想到问题可能出在时钟源本身——LAN9252的25MHz晶振和STM32F103的系统时钟来源不一致二者之间存在频率偏差累积在DC同步过程里就表现为持续的相位漂移。5.2 根因分析25MHz时钟与系统时钟的来源EtherCAT的分布式时钟机制要求所有从站节点能够同步到主站的参考时钟。LAN9252内部有独立的25MHz晶振输入通常由板上的无源晶振或有源振荡器提供。STM32F103的系统时钟则由内部PLL倍频8MHz外部晶振得到典型配置是8MHz HSE经过9倍频得到72MHz。如果LAN9252用的是25MHz无源晶振精度一般在±30ppm以内而在EtherCAT网络中DC同步精度要求通常在微秒甚至亚微秒级。当LAN9252的25MHz时钟和主站的参考时钟存在哪怕几十ppm的偏差经过较长时间的累积从站的SYNC0信号与主站的期望时刻之间就会产生明显的漂移。更严重的是STM32F103本身并不参与EtherCAT的时钟同步它只是作为一个SPI外设与LAN9252交互但如果F103的定时器被用来产生脉宽调制或者输出同步信号而定时器时钟来自内部PLL这个时钟和LAN9252的时钟不是同一来源就无法与EtherCAT网络保持严格同步。另外一个更隐蔽的问题是MCO引脚输出时钟。有些设计为了让LAN9252省掉晶振会使用STM32F103的MCOPA8输出25MHz时钟给LAN9252。理论上可行但F103的PLL配置要能精确产生25MHz的MCO输出。72MHz系统时钟经过3分频正好是24MHz不是25MHz要输出25MHz系统时钟必须是200MHz或者100MHz等能整除的数值而F103最高只有72MHz这个操作实际上行不通。所以在这个方案里LAN9252必须使用独立的25MHz晶振或振荡器不能依赖F103提供时钟。5.3 解决方案MCO输出25MHz与SYNC配置既然F103无法通过MCO输出精确的25MHz那么解决方案就是保证LAN9252使用独立的高精度晶振同时调整F103中所有与同步相关的定时器配置尽量与EtherCAT的SYNC信号对齐。我最终在硬件和软件上做了以下调整第一LAN9252的25MHz晶振选用精度±10ppm以内的贴片晶振负载电容按照数据手册推荐值配置起振电容1μF和22pF并联放在靠近晶振引脚的位置。用示波器测过实际频率精度在±5ppm以内满足EtherCAT的DC同步需求。第二在软件中使能LAN9252的SYNC0和SYNC1输出将SYNC0接回F103的一个定时器输入捕获引脚这样F103可以用硬件方式感知EtherCAT的同步脉冲而不是通过中断软件计数的方式能显著降低抖动。我用的是TIM2的CH1PA0做输入捕获上升沿触发每次捕获到SYNC0脉冲时记录一次计数器值用于校准本地定时器。第三如果应用层需要精确的定时输出比如PWM控制不要依赖F103内部定时器的自由运行模式而是以上一次SYNC0捕获时刻为基准调整下一次PWM的相位对齐。这相当于在软件层面实现了一个小的锁相环把F103的定时器相位锁定到EtherCAT的DC时钟上。当时我把DC同步误差从最初的几十微秒降低到几百纳秒才满足主站的验收要求。这个过程中最大的体会是EtherCAT的同步问题不要一上来就怀疑MCU代码先确认硬件时钟源的精度和一致性往往能省下大量排查时间。6. 坑五电源和PCB走线问题被当成代码bug6.1 现象描述带载后链路不稳定从站放进机柜接上电机驱动器等强干扰负载之后以太网链路频繁断开重连或者出现偶发的丢帧现象。实验室里单独测试一切正常一旦现场环境复杂问题就暴露出来而且完全没有规律可循让人一度怀疑是LAN9252芯片个体差异。这是EtherCAT从站调试中最折磨人的问题也是从“能跑”到“稳定跑”之间的一道坎。问题的根源往往不在代码而在硬件设计中对LAN9252的PHY部分电源和以太网信号走线的处理。6.2 根因分析AVDD/DVDD与100Ω差分阻抗打开LAN9252的芯片手册内部集成了以太网PHY这意味着它对电源噪声和信号完整性有明确要求。手册里把电源分成了好几组数字核心电源、PHY模拟电源AVDD、PHY发送/接收电源等这些电源域在芯片内部是分开的外部也要求提供独立的滤波电路。我最初的设计图里LAN9252的AVDD和DVDD直接连到了一个3.3V电源平面中间没有任何隔离。这个做法在低速SPI通信时问题不大但一旦以太网PHY开始以100Mbps收发数据内部模拟电路的开关噪声会通过电源网络耦合到数字电路造成LAN9252内部的信号时钟抖动反映到网络上就是链路质量下降。另一个大坑是以太网差分信号的阻抗匹配。EtherCAT使用标准100BASE-TX物理层差分信号线的特征阻抗需要控制在100Ω±10%。如果PCB上这对差分线没有按照100Ω差分阻抗设计或者走线绕了太多弯导致长度不匹配信号在传输过程中会发生反射严重时直接导致链路无法建立。6.3 解决方案模块化供电与Layout检查清单针对电源问题我把LAN9252的供电改成了独立模块化设计LAN9252的数字部分DVDD通过磁珠600Ω100MHz从主3.3V隔离出来模拟部分AVDD用独立的π型滤波电路磁珠10μF钽电容100nF陶瓷电容供电两组电源在PCB上物理分开模拟地AGND和数字地DGND在LAN9252芯片下方单点连接以太网信号走线重新按照以下规则检查差分对走线必须计算线宽和间距保证100Ω差分阻抗。在常见的FR4板材介电常数4.2~4.6、1.6mm板厚、表层走线条件下线宽6mil、线距6mil的差分对大致可以满足阻抗要求具体数值需要根据PCB叠层结构用阻抗计算工具确认。差分对内部长度差控制在5mil以内避免相位偏移。差分对远离高速数字信号线和电源走线间距至少3倍线宽。RJ45连接器尽量靠近LAN9252中间不要打过孔换层。如果必须换层换层处要加地过孔围栏。改版之后重新打板测试链路稳定性大幅提升。这里要特别提醒如果怀疑是硬件问题别急着改代码。先用示波器看LAN9252的AVDD电源纹波峰峰值应小于50mV再用网线测试仪或示波器测量差分信号质量基本能定位问题方向。如果条件允许在调试阶段就用带变压器的一体化RJ45座比如HR911105A可以减少外部分立网络变压器的连接错误概率。我见过太多因为网络变压器中心抽头接错导致链路不通的案例用一体化座直接规避了这个风险。7. 从站调试过程中的常见问题速查7.1 BOOT0/BOOT1导致程序不运行在从站设备中F103的BOOT0和BOOT1引脚如果被外部电路拉高或者悬空可能导致芯片从系统存储器ISP模式或SRAM启动用户Flash里的应用程序根本不会执行。表现出来就是设备上电后LAN9252的IRQ没有任何反应SPI也没有任何通信波形排查半天以为是LAN9252的问题其实F103压根没跑起来。解决方案是把BOOT0和BOOT1都用10kΩ电阻下拉到地确保上电后从主Flash启动。如果BOOT0需要引出用于ISP下载也要保证默认状态是低电平只有手动跳线时才拉高。另一个和下载相关的坑是DAP下载失败。F103的SWD接口使用PA13SWDIO和PA14SWCLK如果代码初始化时把这些引脚配置成其他的复用功能调试器就无法连接。遇到DAP下载失败时可以先按住复位键再点击下载让芯片在复位状态下被连接然后再释放复位通常能恢复正常。7.2 串口1与串口3的波特率误差差异很多从站代码用串口做调试输出迁移时要注意F103的串口1挂在APB2上72MHz而串口2/3挂在APB1上36MHz。相同波特率配置下串口3的波特率误差会比串口1大如果用了不太标准的波特率比如250000bps串口3可能根本无法稳定通信。我在调试中就把调试串口固定用USART1PA9/PA10并保留一个USART3作为与上位机的通信接口。如果遇到打印乱码优先查波特率分频系数和APB时钟频率不要怀疑芯片坏了。7.3 用逻辑分析仪快速定位SPI问题调试EtherCAT从站过程中逻辑分析仪是排障利器。没有专业示波器的情况下一台十几块钱的USB逻辑分析仪加上免费的sigrok/PulseView软件就能抓取SPI波形、IRQ电平和复位时序。抓SPI波形时要注意采样率至少是SPI时钟的4倍建议8倍以上。18MHz的SPI时钟最好用100MHz采样率的设备。触发方式设置为CS下降沿触发这样每次通信开始时都能抓住。在解码器里选择SPI协议设置好CPOL和CPHA参数PulseView能自动解析出读写的寄存器地址和数据。有一次排查SPI通信失败逻辑分析仪一眼就看到CS信号在下拉过程中出现了一次毛刺导致LAN9252把一次通信拆分成了两次数据自然不对。后来在CS线上加了一个100Ω串联电阻毛刺消失问题解决。这些东西不抓波形根本想不到。最后再分享一个经验做从站代码迁移一定不要急着把应用逻辑调通先把“最小系统跑起来”作为第一步。所谓最小系统就是F103的时钟、串口打印、SPI通信、LAN9252复位和IRQ全部正常用上位机EtherCAT主站软件扫描到设备并能读取到正确的PDI信息。这一步稳定了后面的应用代码迁移才能建立在可靠的地基上。我当时跳过了这一步直接迁移全部代码结果一个问题的表象背后往往堆着三四个硬件坑排查起来极其痛苦。先稳硬件再调软件顺序别反。