★ FEATURED ARTICLE 做车载和工业控制的朋友一提到英飞凌TC3XX的AURIX系列第一反应肯定是“这个片子就是为功能安全和多任务控制设计的”。项目里的通信骨干十个有八个是CAN总线。TC3XX的CAN模块不是那种常见的邮箱型结构而是从TC2XX继承并增强过的MultiCAN支持CAN 2.0B和CAN FD每个节点都有自己的Message RAM消息对象全靠链表组织。这篇就结合我从TC2XX时代一路用到TC377、TC397的经验把TC3XX的CAN模块从硬件架构、消息对象机制、寄存器配置到工程排错彻底梳理一遍。不管你是刚拿到开发板的新手还是已经在产品上跑CAN的老手这篇都值得收藏慢慢看。1. 硬件架构先把TC3XX的CAN“家底”盘清楚1.1 多节点与时钟域别把CAN当作单一外设TC3XX的CAN和很多MCU不一样它不是“一个控制器、一对收发引脚”那种简单模型。它实际上是多个独立的CAN节点每个节点都是一套完整的MultiCAN控制器。常见的TC377、TC397这类型号CAN节点可以从CAN0一直排到CAN3部分型号还带CAN4。每个节点有自己的控制寄存器、自己的中断指针、自己的Message RAM空间。这意味着你可以把不同节点配置成完全独立的波特率、帧类型和工作模式互不干扰。这个多节点设计在实际项目里非常实用。比如做整车控制器VCU时CAN0接动力域CAN1接车身域CAN2接诊断口三个网络波特率不一样、负载率不一样、安全等级也不一样。如果用传统单CAN控制器要么外接多路CAN芯片要么用软件做网关转发复杂度高还容易出问题。TC3XX直接一个芯片管三个域硬件层面天然隔离软件上每个节点各跑各的任务逻辑清晰。时钟这块是个大坑。TC3XX的CAN模块时钟来源于SPBSystem Peripheral Bus而不是CPU主频。很多人一上来就把CPU主频当CAN时钟去算波特率算出来的预分频值完全不对。TC3XX的SPB时钟一般配置在80MHz或100MHz具体看时钟树初始化怎么设置的。配置CAN波特率之前第一件事就是确认fCAN的实际值最好在调试器里直接读寄存器确认不要凭印象。SPB时钟一旦变了CAN波特率全部跟着变这种问题排查起来很隐蔽。1.2 引脚复用与收发器连接RX/TX不是随便一接就完事TC3XX的CAN收发引脚不是固定的每组CAN_RX和CAN_TX都可以映射到多个物理引脚上。这是好事画PCB时走线方便错开干扰源但也是坑寄存器配错一个引脚模式CAN就闷声不响地“哑”了。配置引脚时一般用IfxPort_setPinMode选择对应的ALT模式。一定要对着芯片手册或iLLD的引脚定义表查清楚不是所有引脚都支持所有CAN节点的复用选错了就是无声无息地没信号。芯片引脚出来的只是3.3V或5V的TTL逻辑电平不能直接怼到CAN总线上。必须在MCU和总线之间加CAN收发器比如TJA1043、TJA1051、TCAN334这类。收发器负责把芯片的TX/RX电平转换成CAN总线的差分电平。这里有个大家经常忽略的事收发器的VIO引脚要跟MCU的IO电压匹配。如果MCU是3.3V收发器VIO接5V那RX引脚输出的高电平就可能超过MCU的承受范围轻则通信异常重则烧引脚。收发器的STB待机或EN引脚也要检查有的板子默认把这个引脚拉高了收发器一直处于待机状态CAN总线波形都看不到还以为是代码问题。终端电阻更是老生常谈。标准CAN总线两端各有一个120欧姆电阻不是每个节点都加。做一些短距离测试时如果只有两个节点两端各放一个120欧姆即可。我见过很多新手板子为了省事一个终端电阻都不焊结果波特率超过250k就开始随机报错有的则加了四五个终端电阻总线负载过重信号幅值直接被拉垮。终端电阻阻值不用纠结120欧姆是标准不要改成100或150去“优化”那只会引入反射。2. 消息对象机制MultiCAN的灵魂2.1 消息对象到底是什么如果只记住一个概念那就是TC3XX的CAN是基于“消息对象”Message Object简称MO工作的。MO不是简单的硬件邮箱它本质上是Message RAM里固定大小的一块数据结构。每个MO占16个字包含控制字、状态字、仲裁字ID和掩码、数据区、功能控制字、时间戳等。每个CAN节点的Message RAM里可以部署几十上百个MO具体数量看型号一般至少128个。这个结构和STM32那种固定几个硬件邮箱的模式完全不一样。STM32的邮箱数量少、配置固定收发要靠软件选择邮箱号而TC3XX的MO更像“内存里的报文条目”你可以把一个MO配成只接收某个ID把另一个MO配成只发送某个ID剩下的MO全部串成FIFO队列。灵活性高了一个量级。代价就是配置复杂必须搞清楚每个控制字每一位的含义不像邮箱那样填个结构体就能跑。从软件角度看MO就是一个内存对象但硬件会自动扫描这些对象并执行匹配。这个“硬件自动扫描”听起来很爽实际用起来要注意你往MO里写数据、改ID、置发送请求都是有顺序要求的。比如发送前要先把数据和ID准备好再触发发送请求位最后硬件从中挑选优先级最高的MO发出。顺序反了可能把旧数据发出去。这些时序细节iLLD库帮你遮掉了一部分但要是自己写寄存器操作就得小心。2.2 优先级仲裁与过滤匹配报文怎么选路MO的仲裁字里存的是ID和掩码的组合。接收时总线上来的每一帧报文都会和所有配置为接收的MO做匹配硬件自动比较ID和掩码。如果多个MO都匹配上了就按优先级规则选一个接收。这个“优先级”不是ID越低越优先而是由MO的全局优先级寄存器MO_GPR决定值高的MO优先匹配。发送侧同理多个发送MO同时挂起时硬件挑优先级最高的先发。有个技巧分享一下利用掩码实现“组接收”。比如你想接收ID 0x100到0x1FF这一整组报文不用每个ID建一个MO一个MO把掩码配成只匹配ID的高8位即可。但注意掩码只是过滤条件它不能告诉你这一组里到底是哪个ID来了。如果业务上需要区分具体ID还得在读数据时自己把ID取出来分析。我最早做诊断应用时就想偷懒用组接收一个MO收一堆ID结果应用层傻傻分不清哪个是哪个最后还是老老实实按ID拆分MO。掩码还有一个典型坑29位扩展帧和11位标准帧不能混在同一个MO的过滤规则里。如果你配了扩展帧掩码位数就要按29位处理标准帧报文直接进不来。项目里如果总线上既有标准帧又有扩展帧建议分开用不同MO别指望着一个过滤器通吃。2.3 FIFO与链表处理突发报文的关键TC3XX的FIFO不是硬件寄存器队列而是把多个MO通过链表“串”起来。每个MO的FCR寄存器里有一个Next字段指向下一个MO的编号硬件会沿着链表顺序写入。这么设计的好处是深度可以自定义你觉得接收报文量大就串16个MO报文不多串4个就够。不像有些芯片的硬件FIFO深度固定想去都去不掉。FIFO在诊断和刷写场景里尤其重要。比如UDS诊断会话设备端会一次性连发好多条请求如果接收缓冲区不够深后面的帧就可能被硬件丢弃。用TC3XX时我习惯把诊断接收通道配成深度为8的FIFO再加一个“水印中断”。水印的意思是FIFO里积攒到一定数量报文时才触发一次中断而不是每收一帧就打断CPU一次。这样CPU负载低逻辑处理也集中。注意水印值不要设太大否则等到中断触发前面应用层的响应时效可能过了尤其诊断超时是硬指标丢一次超时就要重来。发送侧同样可以用FIFO。多个应用任务同时想发CAN帧如果共用同一个发送MO就得加锁排队如果用发送FIFO每个任务往不同的MO槽里填数据硬件自动按顺序发出去。这个设计在RTOS多任务环境下特别省心。3. 寄存器级配置与波特率计算从零初始化一个CAN节点3.1 初始化流程时钟、引脚、模块、节点的顺序不能乱初始化CAN节点的顺序是有讲究的顺序错了轻则配不通重则烧引脚。我自己的标准流程是这样的使能CAN模块时钟。TC3XX的CAN模块有个时钟控制寄存器CAN_CLC必须先把模块从停机状态唤醒。iLLD里对应IfxCan_Can_enableModule函数。很多人第一步就漏了导致后面所有寄存器写了都没反应。配置引脚复用。把CAN_RX和CAN_TX对应的物理引脚设为正确的ALT模式这一步要用PORT模块的寄存器或iLLD端口驱动。初始化CAN模块。设置模块级参数比如时钟分频、中断输出线选择。初始化CAN节点。这一步配置节点的波特率、帧类型经典CAN还是CAN FD、滤波器规则、中断使能。配置消息对象。把需要的MO分别设成发送MO、接收MO或FIFO队列。用iLLD库写的话简洁很多大概长这样#include IfxCan_Can.h #include IfxPort.h /* 配置引脚复用 */ IfxPort_setPinMode(MODULE_P20_10, IfxPort_Mode_input, IfxPort_PadDriver_cmosAutomotiveSpeed1); // CAN0_RXD IfxPort_setPinMode(MODULE_P20_11, IfxPort_Mode_output, IfxPort_PadDriver_cmosAutomotiveSpeed1); // CAN0_TXD /* 初始化模块 */ IfxCan_Can_Config canConfig; IfxCan_Can_initModuleConfig(canConfig, MODULE_CAN0); IfxCan_Can_initModule(g_mcmcan.canModule, canConfig); /* 初始化节点 */ IfxCan_Can_NodeConfig nodeConfig; IfxCan_Can_Node_initNodeConfig(nodeConfig, g_mcmcan.canNode); nodeConfig.baudRate.baudrate 500000; nodeConfig.baudRate.syncJumpWidth 2; nodeConfig.baudRate.samplePoint 80.0f; nodeConfig.baudRate.prescaler 2; nodeConfig.txConfig.txBuffer IfxCan_MessageObject_0; nodeConfig.rxConfig.rxBuffer IfxCan_MessageObject_1; nodeConfig.rxConfig.filterType IfxCan_FilterType_mask; nodeConfig.rxConfig.standardId 0x123; nodeConfig.rxConfig.idMask 0x7FF; IfxCan_Can_initNode(g_mcmcan.canNode, canConfig, nodeConfig);上面的baudRate.prescaler只是示意实际用的时候一定要结合下面说的位时序一起算。iLLD提供samplePoint和prescaler参数它会自动计算TSEG1和TSEG2省了很多事但如果你发现通信波形不好还是要回到手动计算去微调。3.2 位时序与采样点这些参数才是通信稳定的护城河CAN的位时间分成四段同步段、传播段、相位缓冲段1、相位缓冲段2。采样点在相位缓冲段1和2的交界处。TC3XX的节点位时序寄存器N_BTR里主要配三样东西BRP波特率预分频、TSEG1、TSEG2还有一个SJW同步跳转宽度。时间量子tq的计算关系是tq 2 × (BRP 1) / fCAN。一个位时间包含的tq数量NBT 1 TSEG1 TSEG2。采样点百分比 (1 TSEG1) / NBT × 100%。选TSEG1和TSEG2时NBT一般控制在8到25之间太小没有足够的采样精度太大同步能力变差。举个例子。假设fCAN 80MHz目标波特率500kbps。先算总的分频需求80MHz / 500kbps 160意思是每个位时间总共需要160个时钟周期也就是如果BRP0分频2tq就是40MHz一个位有160个tq这显然太多。把BRP设大一点取BRP3则tq 80MHz / (2×4) 10MHz一个位时间需要160 / 4 20个tq刚好在合理范围内。接下来分配TSEG1和TSEG2采样点想做到80%则 (1 TSEG1) / 20 0.8得出TSEG1 15TSEG2 20 - 1 - 15 4。SJW取2到3就够了太大反而容易发生多次重同步造成抖动。我做项目时习惯先画一张表把常用波特率的参数算好备查目标波特率fCANBRP实际分频2×(BRP1)TSEG1TSEG2采样点125 kbps80 MHz1532倍分频tq2.5MHz15480%250 kbps80 MHz716倍分频tq5MHz15480%500 kbps80 MHz38倍分频tq10MHz15480%1 Mbps80 MHz14倍分频tq20MHz15480%采样点这个事低速总线随便配配都能跑但到了500k以上线缆又不短时采样点太靠前或太后都会出现随机错误帧。行业里一般推荐经典CAN采样点设在75%到87.5%之间。如果把采样点设成50%总线上的毛刺很容易被采进来。3.3 CAN FD配置发送和接收要同时升级TC3XX的CAN模块支持CAN FD这是它相比很多老CAN控制器的核心优势。CAN FD有两个关键位FDF位表示是FD帧BRS位表示数据段是否切换到了更高波特率。仲裁段保持经典CAN的波特率数据段可以提升到最高8Mbps甚至更高看收发器能力这样大数据量传输时效率大幅提升。CAN FD的数据段位时序在另一个寄存器N_DBTP里配置跟仲裁段的N_BTR是分开的。这两个东西必须同时配对好。我刚开始玩FD时犯过一个经典错误只改了数据段波特率忘了把仲裁段也验证一遍结果同一个节点在FD模式下数据段正常仲裁段偶尔出错查了半天才发现是两个段参数互相影响。配置CAN FD时还要注意CAN收发器的支持能力。很多老款收发器只支持经典CAN的1Mbps数据段切到2Mbps以上就废了。选收发器时要明确写上“CAN FD ready”或者“ISO 11898-2:2016 compliant”。我做过一个OTA刷写项目仲裁段500k、数据段2M整包刷写时间比传统1M经典CAN还快不少。这个提升在动辄几百KB的升级包里非常明显。CAN FD还有一个坑它和经典CAN不能在同一根总线上随意混用。节点配置成FD模式后如果总线上还有只支持经典CAN的老节点必须把FD使能关掉否则老节点根本看不懂FD帧直接报错。TC3XX每个节点可以独立控制FD使能所以混用场景下要把新老节点分到不同CAN节点上或者老老实实全局禁用FD。4. 中断策略与工程调试别让CAN变成“哑巴”4.1 中断设计收发的三种常见姿势TC3XX的CAN中断不是简单的“收到就中断”。因为MO数量多、FIFO机制灵活中断的触发方式非常多样。最常见的做法是让每个接收MO或FIFO水印触发中断中断服务程序里把数据拷出来置一个软件标志然后交给应用层处理。另一种是轮询主循环定期扫MO的状态位适合低速率、报文少的场景省中断开销。第三种是混合模式比如普通报文轮询收但错误状态和Bus Off用中断立刻通知CPU。中断配置里第一个要注意的是服务请求节点SRN映射。TC3XX的CAN模块中断不是直接连到CPU核心的同一个向量而是通过中断路由器ICU分发。你得指定这个CAN中断用哪个SRN然后在ICU里配置对应的优先级和CPU核心。iLLD里对应的是IfxCan_Can_setNodeInterrupt等接口。我踩过一个坑同一颗TC397双核跑项目把CAN中断配到了CPU0但接收任务跑在CPU1上每次收完报文都要跨核同步白白增加延迟。后来把中断直接配到CPU1性能立刻好转。另一个中断设计的细节是“中断服务程序里别做重活”。CAN中断里只做数据搬移比如从MO内存拷到全局Buffer然后置事件标志真正业务逻辑放到任务里去处理。如果在中断里做超长解析、打印日志不仅阻塞其他中断还可能错过下一个CAN帧造成溢出丢帧。4.2 调试流程从物理层到应用层一步一步来CAN调试最容易翻车的就是“只盯代码不看波形”。我自己的排查顺序固定如下物理层。用示波器或逻辑分析仪测CAN_H和CAN_L之间的差分波形。看有没有“隐性电平1.2V左右、显性电平2.0V左右”一跳一跳的方波。没有波形先查收发器供电、STB引脚、终端电阻、引脚复用。波特率。用示波器量一个显性位的宽度和理论位时间对比。500kbps的位时间应该是2us如果量出来差很多说明位时序配置错了。回环测试。TC3XX的CAN模块支持环回模式把发送输出直接环回到接收端不需要外部总线。先在这个模式下确认MCU内部收发逻辑正常再把收发器接上做外部测试。TC3XX中配置环回模式一般在N_MR寄存器里设置TESTM和LBM位。过滤逻辑。如果回环正常但外部总线收不到特定ID重点检查过滤掩码、MO链表指针、发送请求位有没有置上。示波器探头的接地一定要离测量点近我见过太多人拿长接地夹去测CAN波形测出来的全是噪声还以为总线有问题。另外逻辑分析仪的采样率至少要高于CAN波特率10倍以上否则波形边缘信息缺失很难判断采样点对不对。4.3 错误状态与Bus Off处理不能坐以待毙CAN模块内部有错误计数器。发送错误和接收错误各有一个计数超过一定阈值会进入Error Passive状态再严重就是Bus Off。TC3XX的节点状态寄存器里可以读到这些计数器的值调试时非常有用。Bus Off之后CAN节点会自动离线不参与总线通信。恢复正常需要等待总线空闲连续128个11个隐性位。实际产品里Bus Off处理必须做成自动恢复机制不能死等。我的做法是开启Bus Off中断在中断里记录错误次数然后主动重新初始化节点或者至少把错误计数器归零让模块重新上线。如果连续Bus Off次数超过阈值说明总线上存在严重硬件问题或者波特率完全不匹配这时候要报警而不是无限重连。错误中断还有一个隐藏用途排查电磁干扰。车上环境干扰多CAN总线偶尔出一个位错误很正常但如果错误计数不断累积说明线缆屏蔽、走线、终端电阻肯定有问题。我就会利用CAN模块的错误中断来做故障诊断功能一旦错误帧率超标软件主动记录并上报。5. 供电、Layout与常见问题速查5.1 “CAN通信模块芯片能否给板子供电”这是典型误区网上经常有人问“CAN通信模块芯片能否给板子供电”这其实是个理解偏差。CAN收发器模块比如板子上焊的那个TJA1051芯片它的供电引脚VCC和VIO必须由外部电源电路提供它不是电源芯片没有DC-DC降压或稳压的功能。CAN_H和CAN_L两根线是差分信号线传递的是逻辑电平信息不是能量。想从总线上的两根信号线里抽电流给板子供电不但不可行还会把总线电平拉垮导致所有节点通信失败。那“总线供电”是不是完全没戏也不是但那是另一种方案。工业现场总线里确实有Power over CAN的概念比如在两根电源线上混入CAN差分信号或者在标准的四线制里专门留两根粗线供电。这需要专门的电源管理芯片和网络规划跟MCU的CAN外设没有关系。TC3XX的CAN模块只负责收发差分信号供电方案是电源工程师的活别指望通过CAN外设解决板子供电问题。顺带说一句好多入门者会把“CAN通信模块”理解成那种带隔离的成品模块比如ADM3053。这类型号里确实集成了隔离电源能给自己的隔离侧供电但它的供电也是靠模块外部给VDD或VBUS输入绝不会从CANH/CANL上取电。所以无论哪种形态的CAN模块都改变不了“信号线不供电”这个本质。5.2 PCB Layout别让硬件毁掉软件的心血CAN总线在PCB上的走线质量和通信稳定性直接相关。TC3XX引脚出来的TX/RX是普通数字信号到收发器这段走线短、直问题不大。真正关键的是收发器到总线连接器之间的差分对走线。要求是差分阻抗接近120欧姆两根线尽量等长、等距、紧耦合。如果板子空间紧张至少要保证CAN_H和CAN_L走线不跨越其他高速信号不形成大的环路面积。终端电阻的位置也有讲究。如果这个板子是总线中间的节点不需要终端电阻如果是末尾节点120欧姆电阻应该尽量靠近连接器而不是放在收发器旁边绕一圈再回来。电阻离连接器远等于在终端电阻和总线之间多出一段stub高速时会反射。共模电感串在CAN_H/CAN_L上可以抑制共模干扰但选择时要注意额定电流和直流电阻别引入新的压降。防护器件也不能省。车载环境里总线容易受到静电和浪涌冲击TVS管要接到总线连接器处。很多低成本板子为了省钱省事把TVS和共模电感都砍了结果样品测试时偶尔通信异常查半天最后发现是干扰引起的位错误。CAN之所以被工业界广泛应用就是因为它抗干扰能力相对强但这不是说可以不做防护。5.3 常见问题速查表下面这张表是我这几年排查CAN问题最常用到的基本覆盖了80%的故障现象故障现象可能原因排查/解决办法节点无法进入Bus On收发器供电异常、STB引脚拉高、总线无终端电阻或短路测收发器VCC/VIO测CAN_H/CAN_L直流电压发送即报错波形混乱波特率配置错误收发两端不一致示波器量显性位宽度对照N_BTR寄存器能发不能收过滤器掩码错误、接收MO没使能、RX引脚复用配置错回环测试检查N_RXMO和MO链表能收普通帧CAN FD收不到FD使能没开或数据段波特率不匹配确认N_MR里的FDE位检查N_DBTP偶发错误帧、Bus Off终端电阻缺失/过多、线缆过长、采样点设置不合理优化采样点到80%附近检查总线阻抗上电后寄存器写不进CAN_CLC模块时钟没使能先调用IfxCan_Can_enableModule或直接操作CAN_CLC中断不触发中断路由器ICU配置错误、SRN没映射到正确CPU查ICU的SRC寄存器确认优先级和CPU核心排查时还有一个技巧利用TC3XX的环回模式把软件逻辑和硬件链路切分开。环回模式下报文不经过外部总线MCU的发送直接回到自己的接收端。如果环回能收到说明你的MO、过滤器、中断配置基本没问题问题大概率在收发器或总线上如果环回都收不到那就是芯片内部配置的问题不用动烙铁先查代码。关于“CAN通信模块芯片能否给板子供电”这个认知误区我想多说一句。有些同学看到开发板上有CAN收发器以为CAN总线能像USB那样携带5V供电这其实是因为USB确实有VBUS供电线而CAN没有。CAN总线标准里只有CAN_H和CAN_L两根信号线加上可选的地线。所有节点的供电都靠各自电源总线只解决通信不解决能量。产品设计时哪怕整个系统里只有一个电源入口每个CAN节点的耗电也要自己算清楚指望从总线“蹭电”的方案从一开始就不成立。6. 开发环境与调试工具建议既然聊到TC3XX的CAN模块就绕不开开发工具链。不少人被TC3XX的工程结构劝退其实熟悉了也就那么回事。AURIX Development Studio简称ADS是英飞凌官方的免费IDE基于Eclipse里面集成了HighTec编译器开箱即用适合个人学习和早期验证。商用产品里更多人用Tasking它对AURIX的优化更激进代码量和执行效率都有优势不过要花钱买license。如果你是从TC264这类双核片子转过来的编译器从Tasking切到HighTec或者反过来注意一下内联汇编和关键字兼容性其他地方差别不大。调试器方面Lauterbach Trace32是AURIX圈子里的老牌神器功能强大到可以在线改寄存器、trace内核运行轨迹就是价格劝退。预算有限的团队用PLS UDE也能完成大部分CAN调试重点是看寄存器窗口和内存窗口。DAP miniWiggler是官方低成本方案适合下载和简单调试但复杂一点的波形对比和时序分析还是得靠示波器。CAN总线的专业分析工具BOSCH的CANoe是行业标杆功能全到能模拟整个网络但License不便宜。自己做研发验证用PCAN、USBCAN这类替代品就行配合开源的BUSMaster或PCAN-View抓帧、发帧、看错误帧都够用。我一般先在PC上用USBCAN模拟对端把TC3XX的CAN节点和PC对发确认协议没问题再上真实ECU联调。一个自己的体会调试CAN模块时别一上来就翻几百页的手册。先把示波器接上看波形把物理层排除掉再用回环测试确认芯片内部逻辑最后才轮到分析协议和应用层。顺序对了调试时间至少省一半。很多人卡在CAN 上几天最后发现就是引脚复用配置错这类问题用示波器测一下引脚波形一分钟就能定位。
阅读完成 · 觉得有帮助？
