profinet开发搞IO设备，搞了快两周还没跑通，求问各位
现在在做一个小型改造项目，要把一台原来的单机设备挂到客户的Profinet总线上。设备这边自己做的，STM32H743主控，外接一个LAN9252做PHY+MAC，实际上就是当一个Profinet IO Device用。GSD文件是从协议栈工具里导出来的，名字啥的都改好了。
问题出在PLC那边一扫描就报"station failure"，Wireshark抓包能看到AR建立请求过去了，设备回了AR_Correct响应，但紧接着就是Abort，连正常的参数读写都没进去。检查过站名和IP地址都和GSD里对得上，槽位配置也按0/1/2/3走的。协议栈用的是开源的PROFINET IO Device那套（不是那个PN Stack的商业版，是GitHub上能下的那个），跑在裸机+FreeRTOS上。
想问问有没有搞过这个的老哥，这种AR建立成功又立刻Abort的情况一般是哪里的问题？会不会是vendor/device ID这块我填的不对？
全部回复 (3)
你这情况我去年在F207上干过类似的，症状几乎一模一样，最后查下来是OEM Device ID冲突了。开源的那套协议栈默认的Device ID大概率和你客户PLC项目里已经存在的某个站点撞了，因为Profinet里Device ID是全网唯一的，PLC一比对发现重了就直接Abort，连参数化都不发。你先进PLC的硬件目录里搜一下你这个GSD对应的Device ID在项目里是不是已经存在，或者直接拿PN Inspector这种工具在PC侧模拟PLC扫一下，看看设备响应里报的具体Abort原因码是多少，理论上返回的是"OEM_ID_DIFFERS"或者类似的名字。另外一种可能是Name of Station长度对不上，有些PLC对站名长度敏感，规定必须正好是多少字节，不足的后面要补空格或者特殊填充，开源的GSD生成器这块经常给你漏掉。把你抓包的AR建立阶段完整PDU贴出来看看，光看AR_Correct不够，得看里面的BlockHeader和ARProperties。
裸跑FreeRTOS跑Profinet这事儿本身就不太靠谱，任务调度抖动稍微大一点就会导致DCP响应超时，PLC那边超时阈值默认是1秒还是3秒来着忘了，反正很严格。建议你先把RTOS所有任务都停了，单跑Profinet协议栈一个任务，用最高的优先级，给个10ms以内的周期，看能不能正常建立连接。如果单跑就正常那基本可以确认是调度问题，再去优化其他任务的优先级和栈分配。另外LAN9252的SPI时钟你查查，H743的话SPI外设时钟树配置不对经常导致读取寄存器有延迟，初始化那块多看两遍数据手册。
开源那套协议栈生产环境直接用？还是先评估下稳定性和认证再说吧，工业现场EMC和长期运行这块开源的基本都扛不住，出了问题排查起来要命。我们公司之前也走过这条弯路最后还是换商业的了，许可证费用摊到单个设备上其实没多多少。