手上这块 TC275 Lite Kit 在抽屉里躺了快半年一直没找到合适的理由动它。前阵子接了个小批量的控制器项目需求很硬只能走经典 CAN必须支持 UDS 刷写App 出问题要能刷回来成本还卡得死。选型绕了一圈最后落到了这块板子上——TriCore 三核、4MB PFlash、MultiCAN做CAN UDS Bootloader的验证平台刚好够用而且 AURIX Development Studio 免费iLLD 的底层驱动也齐不用从寄存器一层层啃起。这篇东西不讲空话就是把整个开发过程里我实际做过的事、算过的参数、踩过的坑摊开写一遍。核心关键词就四个TC275 Lite Kit、CAN、UDS、Bootloader但真正决定项目能不能落地的是这四者交界处的那些细节——ISO-TP 分包怎么收、Flash 驱动为什么要拷到 RAM 里跑、27 服务的种子密钥在没 HSM 的芯片上怎么兜底、两兆的包在这条 500k 的总线上要刷多久。适合看的读者大致三类刚上手 AURIX 想找个完整项目练手的嵌入式新人手上有一堆 MCU 平台、想搞明白UDS 刷写流程到底哪几步是必须的的中间件同学还有做诊断规范、需要评估这套方案在量产产线上能不能过的架构同学。我不会假设你懂 TriCore 的 CSA 机制也不会假设你知道 0x78 是什么但我会假设你至少写过一点 CAN 收发代码知道什么叫报文 ID。1. 先把需求拆干净为什么是 TC275 CAN UDS Bootloader1.1 TC275 Lite Kit 这块板子到底给了你什么先把家底盘清楚不然后面聊到资源分配都是空的。TC275 这颗片子是 AURIX 第一代 32 位 TriCore三核CPU0/CPU1/CPU2主频 200MHz4MB 的 Program Flash352KB 左右的本地 SRAM 分散在三个核上另外还有 DFlash 用来做 EEPROM 仿真。片上通信外设是 MultiCAN4 个 CAN Node、128 个 Message Object这个量对做诊断来说绰绰有余。Lite Kit 上的调试器是板载的一颗 XMC1100 做的 DAP 调试器一根 USB 线插上去就能下载和在线调试不用再额外买调试器这一点对个人开发者太友好了。但有个地方必须提前说清楚官方 Lite Kit 的 CAN 信号是引到扩展排针上的收发器不一定焊在板上。我手上这版就没有自己配了一块 TJA1051T/3 的收发模块3.3V 逻辑电平直接和 TC275 的 CAN 引脚对接。你在动手之前先翻一眼自己板子的原理图确认收发器在哪我见过同系列不同批次这里不一样的。另外一个容易忽略的点是电源和终端电阻。CAN 总线两端各需要一个 120Ω 终端电阻做台架调试的时候很多人只在板子这头焊一个另一头用 USB-CAN 盒子自带的结果通信时好时坏。总线上只有一端有终端电阻短距离低速可能勉强能跑但一上 500k、线一长就开始随机丢帧这种问题最难查因为示波器上看波形好像还挺正常。1.2 Bootloader 要解决的三个真问题很多人一上来就写代码写到一半发现需求没想清楚返工。我在动手之前逼自己把 Bootloader 到底要干什么写成了三句话第一句App 必须能被替换。这意味着擦写代码不能放在 App 里否则你把 App 擦了擦写代码本身也没了。所以 Flash 里必须有一块独立区域出厂之后永远不擦这就是 Bootloader 存在的物理意义。第二句替换过程必须可靠。刷到一半断电、刷到一半总线断了、刷进去的包是坏的这三种情况都必须能恢复到至少还能再刷一遍的状态。这就要求 Bootloader 有一个App 是否有效的判断逻辑而不是上电无脑跳 App。第三句替换过程必须可控。谁都可以往 ECU 里刷代码是灾难所以要有安全访问刷完之后要有指纹能追溯产线上要有节拍要求我们这条线要求单件刷写不超过 90 秒含校验。这三句话拆完架构基本就定了Bootloader 独立分区 App 有效标志位 UDS 安全访问 传输完整性校验。后面所有的代码都是围绕这四条在填细节。1.3 为什么不上 CAN FD也不用以太网先说 CAN FD。这颗 TC275 上的 MultiCAN 主要是按经典 CAN 设计的对 CAN FD 的支持很受限而 TC3xx 上的 MCMCAN 才是完整的 FD 实现。所以在这个平台上纠结 FD 意义不大我直接按经典 CAN 500k 来做。那 500k 够不够算一笔账经典 CAN 上一个标准 8 字节数据帧算上帧间隔大概是 110 到 130 个位时间取 120 位。500kbps 下每秒能跑大约 4166 帧。ISO-TP 的连续帧每帧只能塞 7 个有效字节理论极限约 29KB/s实测稳定在 18 到 22KB/s。一个 2MB 的 App光传输就要 95 到 115 秒。这个数字在产线上是紧的但能用——前提是刷写时不能再有别的业务报文抢总线。如果换成 CAN FD同样的包大约能压缩到 20 秒以内这就是为什么新一点的域控制器都在往 FD 上转。但对我们这个项目来说换 FD 意味着换芯片、换收发器、换整条总线的拓扑设计成本上不划算。所以策略是传输协议栈按 CAN FD 兼容的方式写底层驱动保持经典 CAN将来换平台时上层协议基本不用动。至于以太网刷写那是另一个量级的架构DoIP 要完整的 TCP/IP 栈TC275 这个资源做起来性价比太低。选型的核心逻辑是能用简单方案解决的不要为了技术先进性上复杂方案产线上多一个环节就多一个故障点。2. 分区表和启动流程Bootloader 的骨架2.1 Flash 分区怎么切这一步看起来简单其实最容易埋雷。TC27x 的 PFlash 是按 Bank 和 Sector 两级组织的写入的最小单位是一个页擦除的最小单位是一个逻辑扇区。具体的页大小和扇区大小一定要去你手上那颗型号的 Flash 章节确认我见过不同型号差一个数量级的情况。我这份分区表是按 4MB 空间切出来的特意让每一块的起始地址都落在扇区边界上区域起始地址大小擦写策略Bootloader0xA0000000256KB出厂后永不擦除App A0xA00400001.5MB刷写时擦App B0xA01C00001.5MB备用槽A/B 回滚用标定与参数0xA0340000768KB按标定流程单独擦Boot 参数区DFlash0xAF0000008KB存有效标志、指纹、重试计数这里有两个设计决定值得解释。第一个是A/B 双槽。单槽刷写的问题是擦除 App 的那一刻车上是没有任何可运行程序的一旦这时候断电ECU 就是块砖。双槽的做法是 App 在 A 槽跑的时候新固件往 B 槽写写完校验通过改一下参数区里的当前有效槽标志复位后从 B 槽启动。整个过程里始终有一份完整可运行的 App风险低得多。代价是 Flash 直接少了一半但 4MB 的片子上装 1.5MB 的 App还是撑得住的。第二个是参数区放在 DFlash 而不是 PFlash。刷写状态、重试计数这类数据需要频繁更新放在 PFlash 里意味着每次都要擦一个扇区寿命和速度都不划算。DFlash 就是为这种场景设计的刷新粒度小得多。但注意一点DFlash 不是无限寿命的状态写入要做频率控制别每一帧数据都去写一次。2.2 上电之后的启动流程AURIX 复位之后只有 CPU0 在跑CPU1 和 CPU2 停在 halt 状态要由 CPU0 通过寄存器把它们放出来。这个特性和很多双核 MCU 不一样第一次接触容易蒙。Bootloader 阶段我通常不释放 CPU1/CPU2就让它们停着等到跳 App 之前再由 App 自己的启动代码去释放——这样职责清晰也不会出现 Bootloader 改了外设、App 起来一脸茫然的情况。完整的上电流程大概长这样上电复位CPU0 从 Boot ROM 执行跳到 PFlash 里 Bootloader 的启动代码。启动代码做最基础的自检时钟初始化、基本 RAM 检查、看门狗配置。读 DFlash 参数区看App 有效标志和当前有效槽。标志有效且校验通过就跳 App标志无效或校验失败就停在 Bootloader 里等诊断请求。如果停在 Bootloader先给一段等待窗口我设的 500ms窗口内没收到诊断请求就直接尝试跳 App避免正常上电也被诊断流程拖慢。第 5 步这个等待窗口是被逼出来的。最开始我写的是没有有效 App 就一直等诊断结果发现正常量产件上电后也要在 Bootloader 里耗着等 S3 超时才跳走整车下电上电的体验很差。改成短窗口 主动跳转之后正常上电的启动时间从 5 秒压到了 600 毫秒以内。2.3 从 Boot 跳到 App 的几个硬骨头跳转这件事新手最容易写成一句函数指针调用就完事然后 App 跑起来各种玄学问题。TriCore 上有几个东西必须在跳转前处理干净。第一是BIV 寄存器。TriCore 的中断向量表和 ARM 那种固定在地址 0 的不一样它由一个叫 BIV 的寄存器指定基地址。Bootloader 里配置过 BIV如果不重置就跳过去App 里发生中断时会跳到一个已经不存在的向量表上症状是一有中断就跑飞。做法是跳转前把中断全部关掉、清掉挂起的中断标志让 App 的启动代码重新设置 BIV。第二是CSA 链表。TriCore 的函数调用和中断上下文不是存在传统栈里的而是存在 DSPR 里的一条叫 CSA 的链表中由 PCXI、FCX、LCX 这几个寄存器维护。Bootloader 运行时这条链已经用了不少节点直接跳过去的话App 起来后接着用这条旧链容易出现莫名其妙就复位。规范做法是跳到 App 的 Cstart 而不是 main让 App 的启动代码把整条链重新初始化一遍。第三是看门狗。AURIX 上安全看门狗不能彻底关掉只能改超时时间。擦 Flash 的时候 CPU 会被 stall喂狗必须靠定时器中断或者独立的核来做不能指望主循环里那句喂狗。我这里的做法是擦写期间把安全看门狗的超时时间放长同时用一个定时器中断按时喂擦完再改回来。第四是EndInit 保护。AURIX 上很多关键寄存器受 EndInit 保护写之前必须用密码解除。我第一次写 Flash 控制寄存器完全不生效查了半天才发现是这个。密码通过 iLLD 里那两个接口拿一个取 CPU 看门狗密码一个取安全看门狗密码用完记得重新上锁。3. CAN 驱动与 ISO-TP把诊断报文收进来3.1 MultiCAN 的节点和 Message Object 规划TC275 的 MultiCAN 支持把不同 Node 分配给不同 CPU中断也可以路由到指定核。既然 Bootloader 只在 CPU0 跑我就把 CAN0 整个划给 CPU0 专用其余 Node 留给 App 阶段用。Message Object 的分配上有个经验不要把每个要收的 CAN ID 都单独配一个 MO那样 MO 很快就不够用了而且改 ID 就得重配。更好的做法是利用 MultiCAN 的 ID 掩码过滤把一段连续的 ID 一次性收进同一个 MO配合 FIFO 模式让软件层去区分具体是哪个 ID。方向CAN ID类型用途MO 配置收0x7E0标准帧物理寻址诊断请求MO0单 ID 精确过滤收0x7DF标准帧功能寻址广播请求MO1单 ID 精确过滤发0x7E8标准帧诊断响应MO2发送队列关于CAN 报文里的 ID 代表什么这里可以顺手说清楚11 位 ID 不是地址它同时承担两个职责——标识这条报文是什么以及决定仲裁优先级。ID 数值越小优先级越高。诊断常用的 0x7E0 系列属于中等优先级如果总线上有一堆 0x1xx 的实时控制报文在跑诊断帧会被持续压制表现为偶发响应超时。这也是为什么刷写应该走独立诊断口或者独占总线。3.2 位定时参数怎么算包括那个 SJW位定时算错是 CAN 通信最隐蔽的故障来源之一因为低速短距离下算错也能跑一上负载就开始随机错误。我把计算过程完整写一遍。先确定 CAN 控制器的输入时钟。这颗片子上经过分频后可以拿到 40MHz 的 CAN 时钟。目标波特率 500kbps也就是每位 2000ns。第一步算时间份额选分频系数为 4那么一个 tq 4 / 40MHz 100ns。第二步算每位需要多少个 tq2000ns / 100ns 20 tq。第三步分配段位时间 同步段 时间段 1 时间段 2 1 TSEG1 TSEG2 20。采样点希望落在 80%也就是 (1 TSEG1) / 20 0.8得到 TSEG1 15TSEG2 4。验证一下1 15 4 20正确。第四步定 SJW。SJW 是重新同步跳转宽度用来吸收振荡器偏差和位填充造成的相位抖动取值不能超过 TSEG2。我取 3留一点余量。参数取值说明CAN 时钟40 MHz分频前分频系数4tq 100 ns每位 tq 数20500 kbpsTSEG115传播段 相位缓冲段 1TSEG24相位缓冲段 2采样点80%(115)/20SJW3不超过 TSEG2提示采样点位置不是随便定的。如果你要和别人已有的 ECU 挂在同一条总线上务必查一下对方的采样点设置。我用 80%对方用 87.5%两边都能单独通信但一上长线就开始间隔性出错这种问题查起来非常痛苦。3.3 ISO-TP 分包重组UDS 的数据通道UDS 报文最长可以到 4095 字节CAN 一帧最多 8 字节中间必须有一层传输协议来分包这就是 ISO-TP也就是 ISO 15765-2。四种帧类型一定要背下来单帧 SF一帧装得下首字节高 4 位是 0低 4 位是数据长度。首帧 FF多帧数据的开头首两字节是 0x1 加 12 位总长度。连续帧 CF后续数据首字节高 4 位是 2低 4 位是序号从 1 开始循环。流控帧 FC接收方告诉发送方你可以发几帧、帧间隔多少。下位机实现里接收方向相对简单因为上位机发请求一般不会很长发送方向才是重点因为响应里可能有几百字节的数据比如读一组 DID。我踩过的一个坑是流控帧里的 BS 和 STmin 必须严格按收到值执行不能自己拍脑袋改。有一次为了提速我在发送侧无视了上位机给的 STmin结果上位机的接收缓冲溢出直接丢帧表现为刷写刷到一半报长度错误。STmin 的处理还有个细节标准规定 0x00 到 0x7F 表示毫秒0xF1 到 0xF9 表示 100 到 900 微秒。很多 MCU 的定时器精度做不到微秒级我的做法是把 0xF1 到 0xF9 一律按 1 毫秒处理虽然慢一点但绝对不会出错。刷写的时候上位机一般会给 STmin 0那就退化成发完一帧立刻发下一帧靠总线本身的位时间来自然间隔此时驱动要保证发送请求不丢。4. UDS 服务裁剪与 Flash 驱动下载4.1 必须实现的服务清单UDS 定义了二十多个服务但 Bootloader 里真正必须实现的没那么多。我把这份清单按优先级列出来加粗的是不实现就跑不起来的SID服务子功能必要性说明0x10诊断会话控制0x01/0x02/0x03必须进编程会话的前提0x11ECU 复位0x01/0x03必须刷完跳 App 的触发手段0x27安全访问0x01/0x02必须防误刷的第一道门0x34请求下载—必须告知地址和长度0x36数据传输—必须真正的数据搬运工0x37请求退出传输—必须结束传输并回校验结果0x31例程控制0x01/0x02/0x03必须擦除、校验、依赖检查0x3E会话保持0x00必须否则 S3 超时踢出编程会话0x22按标识读数据—强烈建议指纹、版本号读取0x85DTC 设置控制0x01/0x02建议刷写期间抑制故障码0x28通信控制0x00/0x01/0x03建议刷写期间关普通通信0x14清除故障码—建议刷完清一次0x19读取故障码0x02建议产线会读刷写失败记录0x2E按标识写数据—可选写指纹信息关于 0x19 服务这里多讲一句。刷写失败要在 ECU 里留下痕迹产线读 DTC 就是为了区分这个件是刷写失败了还是这个件本身有硬件故障。我的做法是在 Bootloader 参数区记录最近三次刷写的结果状态App 起来之后把它转成对应的故障码。这样即使 ECU 已经跳到 App诊断仪照样能读到历史。4.2 27 服务没有 HSM 的芯片上怎么兜底TC275 这颗片子没有独立的硬件安全模块这一点在方案评审时被人问过很多次。没有 HSM 意味着种子密钥算法只能跑在主核的普通代码里理论上只要拿到 Flash 读出内容就能反推出密钥。这是硬件决定的不是实现问题。那怎么办我的应对策略是分层第一层安全访问本身还是要做的它能拦住 90% 的误操作和非授权工具。种子由下位机用真随机数发生器或者至少是一个足够好的伪随机序列生成每次会话都不一样密钥算法用对称加密密钥不硬编码在代码里而是放在 DFlash 的一个受保护区域配合 Flash 读保护。第二层靠调试口锁定兜底。量产件出厂时把调试接口锁掉这样别人拿不到 Flash 内容密钥就推不出来。开发件保留调试口方便排查。这个切换要在产线流程里做成一个明确的工序。第三层靠刷写指纹做追溯。每一次成功的刷写在参数区留下时间戳和固件指纹出问题能查是谁什么时候刷的。具体到协议层安全等级我用 0x01请求种子是子功能 0x01发送密钥是 0x02。连续三次密钥错误就锁定需要等一段延时才能重试。这个延时一定要做在 ECU 侧而不是上位机侧否则暴力破解工具直接无视上位机的等待逻辑就行。4.3 Flash 驱动为什么要拷到 RAM 里跑这是整个项目里最反直觉的一点理解不了它后面的代码就写不对。Flash 的擦除和写入是通过一组控制寄存器完成的而这些寄存器需要 CPU 去读写。问题在于当你正在擦除某个 PFlash 扇区时如果执行代码也在同一个 Bank 里CPU 取指就会 stall程序名义上卡住了。AURIX 的 PFlash 分了多个 Bank支持在一个 Bank 擦写时从另一个 Bank 取指这个特性叫 Read-While-Write。理论上可以利用这个特性直接把擦写代码放在 Flash 里跑但实际工程里大家还是倾向于把 Flash 驱动做成一个独立的二进制镜像通过 34/36/37 服务下载到 RAM 再执行。这么做的理由有三个。一是安全RAM 里的驱动只在这一个刷写会话里存在刷完就没了不会污染 Flash 布局。二是可替换不同批次的芯片 Flash 控制器行为可能有微小差异驱动独立成镜像之后只要换一个 bin 文件Bootloader 本体不用重编。三是规避依赖驱动里不能调用 Bootloader 的任何函数它必须是完全自包含的这样才能保证在任何地址执行都正常。具体的做法是把 Flash 驱动的源码单独建一个工程编译时指定链接到 RAM 地址段我用 DSPR 的高地址区产出一个纯二进制的 bin。上位机刷写流程的阶段一就是把这个 bin 通过 UDS 下载进去然后用 0x31 服务触发它执行。注意Flash 驱动里绝对不能有对 Bootloader 全局变量、常量表、字符串的引用。我曾经因为驱动里 printf 了一个字符串常量导致整个镜像的定位信息错乱下载进 RAM 之后一调用就跑飞查了两天才发现。5. 刷写实操从上位机脚本到 App 跑起来5.1 上位机用 Python 搭一套刷写脚本产线上当然用 CANoe 或者专用刷写工具但开发阶段用 Python 更灵活改一行就能重跑。我用的组合是 python-can 负责报文收发isotp 负责 ISO-TP 层udsoncan 负责 UDS 层三个库各司其职装起来就三条 pip 命令。import can import isotp import udsoncan from udsoncan.connections import PythonIsoTpConnection from udsoncan.client import Client from udsoncan import MemoryLocation # 1. 物理层我用的是 PCAN 盒子也可以换成 socketcan 或者 vector bus can.interface.Bus(interfacepcan, channelPCAN_USBBUS1, bitrate500000) # 2. 传输层参数这几个值要和下位机对得上 tp_params { stmin: 1, # 连续帧最小间隔毫秒 blocksize: 8, # 每轮流控允许的帧数 ll_data_length: 8, rx_flowcontrol_timeout: 1000, # N_Bs rx_consecutive_frame_timeout: 1000, # N_Cr } addr isotp.Address(isotp.AddressingMode.Normal_11bits, txid0x7E0, rxid0x7E8) stack isotp.CanStack(busbus, addressaddr, paramstp_params) conn PythonIsoTpConnection(stack) # 3. 诊断层 with Client(conn, request_timeout5) as cli: cli.change_session(0x03) # 先到扩展会话 cli.change_session(0x02) # 再进编程会话 seed cli.request_seed(0x01) # 拿种子 key calc_key(seed) # 本地算密钥 cli.send_key(0x02, key) # 发密钥 # ... 后续下载 Flash 驱动、擦除、写入这段代码里有两个地方值得说。第一是STmin 和 BS 的取值必须和下位机的实现匹配我这边下位机是严格按收到的流控帧执行所以上位机给多少它就照做不会自作主张。第二是会话切换要走两步很多实现从默认会话直接跳到编程会话会返回否定响应稳妥的做法是先到扩展会话再到编程会话。5.2 完整刷写时序一步都不能省把整个过程按时间顺序摊开是这样的进入扩展会话0x10 03读一遍当前版本和指纹0x22。安全检查0x27拿种子、算密钥、发密钥。切换到编程会话0x10 02。关掉普通通信和 DTC 记录0x28 03、0x85 02。下载 Flash 驱动到 RAM0x34 / 0x36 / 0x37。用 0x31 触发擦除例程例程 ID 0xFF00擦除目标槽位。下载 App 固件0x34 / 0x36 / 0x37分块传输。用 0x31 触发校验例程0xFF01下位机自己算一遍 CRC 比对。用 0x31 触发依赖检查例程0xFF02确认版本兼容。写指纹和有效标志到 DFlash。ECU 复位0x11 01从新槽位启动。第 6 步到第 8 步这三个例程 ID 是 ISO 14229-1 附录例子里给的约定值很多 OEM 会改成自己的编号别直接照抄一定按你们的诊断规范来。我见过有人拿着别家的规范刷自己的件卡在例程不支持的否定响应上查了一整天。另外第 7 步有个容易被忽略的点34 服务里的地址和长度字段格式不是固定的地址和长度各占几个字节由请求里的一个参数决定常见是 4 字节地址加 4 字节长度但也有用 3 字节的。上位机算错字节数下位机解析出来的地址就是乱的表现是写进去了但读出来全不对。我建议在 Bootloader 里对长度字段做严格的范围检查超出分区边界直接返回请求超出范围的否定响应。5.3 下位机的擦写骨架下位机这部分重点是三个动作擦一个扇区、写一个页、校验。写页的顺序不能乱AURIX 的 PFlash 带 ECC一个页必须一次性把所有字都装配完再触发写入中途去写别的页会破坏 ECC 结构。骨架大致是这样#include IfxFlash.h #include IfxScuWdt.h static uint16 g_safetyPwd; /* 擦除一个扇区sectorAddr 传扇区首地址 */ boolean Boot_EraseSector(uint32 sectorAddr) { g_safetyPwd IfxScuWdt_getSafetyWatchdogPassword(); IfxScuWdt_clearSafetyEndinit(g_safetyPwd); IfxFlash_eraseSector(sectorAddr); IfxScuWdt_setSafetyEndinit(g_safetyPwd); /* 擦除是异步的必须轮询等到控制器不忙 */ return IfxFlash_waitUnbusy(0, IfxFlash_FlashType_P0); } /* 写一个页要求 4 字节对齐且该页必须是已擦除状态 */ boolean Boot_WritePage(uint32 pageAddr, const uint8 *data, uint32 len) { uint32 i; if ((len % 4) ! 0) { return FALSE; /* 页写入必须按字对齐 */ } g_safetyPwd IfxScuWdt_getSafetyWatchdogPassword(); IfxScuWdt_clearSafetyEndinit(g_safetyPwd); IfxFlash_enterPageMode(pageAddr); for (i 0; i len; i 8) { uint32 low data[i] | (data[i1] 8) | (data[i2] 16) | (data[i3] 24); uint32 high data[i4] | (data[i5] 8) | (data[i6] 16) | (data[i7] 24); IfxFlash_loadPage(pageAddr, low, high); } IfxFlash_writePage(pageAddr); IfxScuWdt_setSafetyEndinit(g_safetyPwd); return IfxFlash_waitUnbusy(0, IfxFlash_FlashType_P0); }接口名字和参数按你手上 iLLD 的版本核对一遍不同版本之间小有出入但整体思路是一致的先解保护再操作再等控制器不忙最后重新上锁。少任何一步都会出问题。还有一个经验擦除之后不要拿读出来全是 0xFF当擦除成功的判据。带 ECC 的 Flash 在页被正式写之前读回来的内容不一定是你期望的值甚至可能报 ECC 错误。用官方的擦除验证接口或者干脆自己算一遍校验和比对比目测字节可靠得多。5.4 总线负载率算一笔账别把诊断线跑爆刷写之前我一直觉得就一条诊断报文能占多少带宽直到第一次实测发现总线负载率飙到 95% 以上。算一遍就明白了。500kbps 下一个标准 8 字节数据帧的位时间构成是帧起始 1 位、仲裁段 12 位、控制段 6 位、数据段 64 位、CRC 段 15 位、应答段 2 位、帧结束 7 位、帧间隔 3 位合计 110 位再算上最坏情况约 20% 的位填充按 120 位估。每秒可传 500000 / 120 约等于 4166 帧。ISO-TP 的连续帧每帧带 7 个有效字节所以理论吞吐 4166 × 7 约等于 29.2KB/s。实际扣掉流控帧、UDS 服务头、最后一帧装不满的尾巴能稳定跑到 18 到 22KB/s。项目数值备注波特率500 kbps经典 CAN单帧位时间约 120 位含位填充余量峰值帧率约 4166 帧/秒理论值单帧有效载荷7 字节ISO-TP 连续帧理论吞吐约 29.2 KB/s满载实测吞吐18 ~ 22 KB/s含各类开销2MB 固件传输时间约 95 ~ 115 秒纯传输含擦除校验总耗时约 150 ~ 180 秒实际产线数据结论很清楚刷写期间这条总线基本就是被诊断报文占满了别的节点想发报文会被仲裁机制持续压制。所以刷写一定走独立诊断口或者在产线上用专门的刷写工位不要和整车功能总线混在一起。如果实在避不开就把流控帧的 BS 设成较小的值中间插一些空闲时间让其他节点有机会发报文代价是刷写时间拉长。6. 踩坑实录与排查速查表6.1 现象、原因、处理调试过程中攒下来的一批典型问题整理成表遇到类似症状可以按图索骥。现象最可能的原因处理方式27 服务一直返回条件不满足没先进扩展会话或当前会话不允许先切 0x10 03再切 0x10 02发送响应后上位机收不到发送侧 ID 或 ISO-TP 层配置错误抓总线确认实际发出去的 ID刷到一半报块序号错误连续帧序号没循环处理检查 CF 序号是否从 1 到 15 后回 1单帧收发正常多帧必失败流控帧参数没按收到值执行核对 BS 和 STmin 的解析逻辑擦除成功写入后读出来不对页没一次性装配完整ECC 破坏检查写页前是否所有字都 load 完刷完跳 App 立刻复位BIV 未重置中断向量漂移跳转前清中断和 BIV上电偶发不启动App 有效标志写入和断电时序竞争标志写入用双副本加校验通信偶发错误负载越高越频繁采样点和对方不一致或 SJW 过小统一采样点SJW 留够余量第一次写 Flash 寄存器无效EndInit 保护未解除写前用密码解除写完重新上锁编程会话里响应突然变慢下位机没有及时发 0x78长耗时操作前先发响应挂起这里重点说两个。第一个是0x78 响应挂起。擦除一个扇区、校验一大块数据这些操作耗时可能超过 P2Server 的时间上限一般 50 毫秒。这时候下位机必须先回一个否定响应响应码是 0x78告诉上位机我还在处理你再等等把计时器切到 P2*Server一般 5000 毫秒。如果没有这个机制上位机在 50 毫秒后就判超时了而下位机还在勤勤恳恳地擦 Flash等你擦完再发响应那边早就放弃了。这是个纯靠协议约定解决时序问题实现起来就几行代码但不写就一定会出问题。第二个是App 有效标志的写入顺序。跳 App 的判据是参数区里一个标志这个标志写早了万一下载其实没完成上电就跳到一份残缺的 App 上写晚了万一下一次断电前没写成又退回了旧 App。我的做法是校验通过之后写标志标志用两份互为补码的副本存储读的时候两份都读出来比对不一致就按无效处理。看似冗余但断电恰好发生在写入那几毫秒的概率虽小量产后总会碰上。6.2 不小心刷成砖了怎么救这个必须提前准备好不然真出事的时候只能换件。AURIX 的可用手段是启动模式选择。芯片上电时会读一组启动模式相关的配置如果配置成从内部 Flash 启动那就直接跑上面的程序如果配置成从别的接口启动就能绕过 Flash。具体到你这个板子有哪些模式、怎么触发一定去看启动章节和板子原理图。我的做法是在开发阶段就留一条物理的强制进 Bootloader路径比如一个跳线或者特定的引脚组合。板子上电时检测这个状态如果被拉住了无论 App 有效标志是什么都强制停在 Bootloader 里等诊断绝不跳 App。这样只要硬件还能上电就一定能刷回来。工装上的准备也很重要。Lite Kit 上板载调试器插上 USB 就能用调试工具直接擦 Flash这是最省事的救砖手段。但如果你的量产件没有引调试口就只能在 Bootloader 里多留几条后路比如支持功能寻址的广播进编程会话这样即使诊断 ID 配错了也有机会救回来。注意救砖路径不要做得太好用。我见过有人把收到某个特殊诊断请求就无条件擦除 App做成了救砖机制结果产线上误触发一批件全被擦了。救砖通道要有明确的前置条件最好配合物理状态。6.3 几个反直觉的细节最后列几个我踩过、但常规文档里不太会写的点。第一个擦除后的内容不等于 0xFF。带 ECC 的 Flash 在页被正式编程之前读出来的内容是不确定的甚至可能触发 ECC 错误告警。这不是擦除失败是正常的物理状态。别用它当判据。第二个如果你在产出代码里用了 Flash 驱动目录之外的任何文件链接大概率会出问题。因为 Flash 驱动的镜像需要保证在任何地址都能执行任何绝对地址引用都会破坏可重定位性。这一点在编译和链接选项上要专门配置不能沿用普通工程。第三个擦写时间不是线性的。同样的扇区擦第一个和擦第八个耗时可能差别不小因为控制器内部有编程和擦除的时间约束。产线节拍评估时一定要按实测最坏值算不能用平均值乘数量我吃过这个亏理论算出来 90 秒实测峰值到了 130 秒。第四个会话保持一定要做。编程会话的 S3 超时一般是 5000 毫秒上位机在此期间不发任何报文ECU 就会退回默认会话接下来的一切操作都会返回条件不满足。稳妥的做法是上位机每 2 秒发一次 0x3E 00。别把间隔卡到 4.9 秒总线一抖动就超时了。7. 往量产走几个工程化上的考虑7.1 防盗刷和指纹管理开发阶段和量产阶段的要求完全不同。开发阶段我们希望越透明越好量产阶段则要求非授权工具绝对不能刷进去。除了前面说的安全访问和调试口锁定还有两件事要做。第一是固件签名校验。上位机刷进来的固件除了 CRC还要带一段由厂商私钥生成的签名Bootloader 用烧在芯片里的公钥验签。这样即使有人绕过了安全访问也刷不进自制的固件。第二是指纹唯一化。每一件的刷写时间、固件版本、刷写次数都要写进 DFlash产线可以通过诊断读取这些信息售后也能据此判断是不是原厂刷写。这两个机制一定要在 Bootloader 的第一版就设计进去因为后期往已经量产的件上加等于所有件都得重新刷一遍。7.2 版本管理和诊断数据库诊断数据库CDD 或者 ODX 文件和代码必须同源管理。我见过太多项目是代码改了一个 DID 的地址数据库文件没更新产线的诊断仪拿着旧数据库去读读出来全错然后一堆人开始怀疑下位机有 bug。我的做法是把 DID 定义、例程 ID、否定响应码这些全部集中到一个头文件里两边都从这个头文件生成。代码编译时引用它诊断数据库生成脚本也读它从源头上避免不一致。这个投入在项目初期看着有点多余到项目后期会省下大量扯皮时间。7.3 OTA 和 Bootloader 到底什么关系经常有人问我已经做了 OTA还需要 Bootloader 吗。这两件事根本不是同一个层面的东西。OTA 解决的是怎么把固件包从云端送到车端它关心的是通信链路、断点续传、包的完整性。Bootloader 解决的是拿到包之后怎么把包写进 Flash它关心的是擦写、校验、回滚。OTA 的最后一公里永远要落到 Bootloader 上。车端的 OTA 模块下载完固件包最终还是要通过诊断协议把数据交给 Bootloader让它去执行擦写。区别只在于这条链路是走车内总线还是走本地接口。所以一个设计良好的 Bootloader天然就能支撑 OTA不需要为 OTA 单独再做一套刷写逻辑。反而要注意的是OTA 场景下断电的概率比产线高得多因为车可能在任意时刻下电。这就要求 A/B 双槽和有效标志的容错逻辑做得更扎实最好在每次写入关键数据之后都做一次掉电一致性检查。这套东西从空白工程到在板子上完整跑通一遍刷写我大概花了三周其中一半时间花在查 CAN 通信的偶发错误和 Flash 写入的细节上。要说最值得分享的一条经验在动手写 UDS 之前先把 CAN 层调通并且用示波器确认采样点和电平完全正常。我一开始图快CAN 收发还没完全稳定就开始写协议栈结果后面每一个异常我都要分成是协议问题还是物理层问题来排查效率极低。把底层一次做扎实上层调试会顺很多。另外一个小心得Flash 驱动的镜像最好在项目一开始就独立出来编译哪怕当时只有一个空函数。等写到后面再拆分链接脚本和编译选项的坑会让你怀疑人生。 TC275 Lite Kit CAN UDS Bootloader开发实战
手上这块 TC275 Lite Kit 在抽屉里躺了快半年一直没找到合适的理由动它。前阵子接了个小批量的控制器项目需求很硬只能走经典 CAN必须支持 UDS 刷写App 出问题要能刷回来成本还卡得死。选型绕了一圈最后落到了这块板子上——TriCore 三核、4MB PFlash、MultiCAN做CAN UDS Bootloader的验证平台刚好够用而且 AURIX Development Studio 免费iLLD 的底层驱动也齐不用从寄存器一层层啃起。这篇东西不讲空话就是把整个开发过程里我实际做过的事、算过的参数、踩过的坑摊开写一遍。核心关键词就四个TC275 Lite Kit、CAN、UDS、Bootloader但真正决定项目能不能落地的是这四者交界处的那些细节——ISO-TP 分包怎么收、Flash 驱动为什么要拷到 RAM 里跑、27 服务的种子密钥在没 HSM 的芯片上怎么兜底、两兆的包在这条 500k 的总线上要刷多久。适合看的读者大致三类刚上手 AURIX 想找个完整项目练手的嵌入式新人手上有一堆 MCU 平台、想搞明白UDS 刷写流程到底哪几步是必须的的中间件同学还有做诊断规范、需要评估这套方案在量产产线上能不能过的架构同学。我不会假设你懂 TriCore 的 CSA 机制也不会假设你知道 0x78 是什么但我会假设你至少写过一点 CAN 收发代码知道什么叫报文 ID。1. 先把需求拆干净为什么是 TC275 CAN UDS Bootloader1.1 TC275 Lite Kit 这块板子到底给了你什么先把家底盘清楚不然后面聊到资源分配都是空的。TC275 这颗片子是 AURIX 第一代 32 位 TriCore三核CPU0/CPU1/CPU2主频 200MHz4MB 的 Program Flash352KB 左右的本地 SRAM 分散在三个核上另外还有 DFlash 用来做 EEPROM 仿真。片上通信外设是 MultiCAN4 个 CAN Node、128 个 Message Object这个量对做诊断来说绰绰有余。Lite Kit 上的调试器是板载的一颗 XMC1100 做的 DAP 调试器一根 USB 线插上去就能下载和在线调试不用再额外买调试器这一点对个人开发者太友好了。但有个地方必须提前说清楚官方 Lite Kit 的 CAN 信号是引到扩展排针上的收发器不一定焊在板上。我手上这版就没有自己配了一块 TJA1051T/3 的收发模块3.3V 逻辑电平直接和 TC275 的 CAN 引脚对接。你在动手之前先翻一眼自己板子的原理图确认收发器在哪我见过同系列不同批次这里不一样的。另外一个容易忽略的点是电源和终端电阻。CAN 总线两端各需要一个 120Ω 终端电阻做台架调试的时候很多人只在板子这头焊一个另一头用 USB-CAN 盒子自带的结果通信时好时坏。总线上只有一端有终端电阻短距离低速可能勉强能跑但一上 500k、线一长就开始随机丢帧这种问题最难查因为示波器上看波形好像还挺正常。1.2 Bootloader 要解决的三个真问题很多人一上来就写代码写到一半发现需求没想清楚返工。我在动手之前逼自己把 Bootloader 到底要干什么写成了三句话第一句App 必须能被替换。这意味着擦写代码不能放在 App 里否则你把 App 擦了擦写代码本身也没了。所以 Flash 里必须有一块独立区域出厂之后永远不擦这就是 Bootloader 存在的物理意义。第二句替换过程必须可靠。刷到一半断电、刷到一半总线断了、刷进去的包是坏的这三种情况都必须能恢复到至少还能再刷一遍的状态。这就要求 Bootloader 有一个App 是否有效的判断逻辑而不是上电无脑跳 App。第三句替换过程必须可控。谁都可以往 ECU 里刷代码是灾难所以要有安全访问刷完之后要有指纹能追溯产线上要有节拍要求我们这条线要求单件刷写不超过 90 秒含校验。这三句话拆完架构基本就定了Bootloader 独立分区 App 有效标志位 UDS 安全访问 传输完整性校验。后面所有的代码都是围绕这四条在填细节。1.3 为什么不上 CAN FD也不用以太网先说 CAN FD。这颗 TC275 上的 MultiCAN 主要是按经典 CAN 设计的对 CAN FD 的支持很受限而 TC3xx 上的 MCMCAN 才是完整的 FD 实现。所以在这个平台上纠结 FD 意义不大我直接按经典 CAN 500k 来做。那 500k 够不够算一笔账经典 CAN 上一个标准 8 字节数据帧算上帧间隔大概是 110 到 130 个位时间取 120 位。500kbps 下每秒能跑大约 4166 帧。ISO-TP 的连续帧每帧只能塞 7 个有效字节理论极限约 29KB/s实测稳定在 18 到 22KB/s。一个 2MB 的 App光传输就要 95 到 115 秒。这个数字在产线上是紧的但能用——前提是刷写时不能再有别的业务报文抢总线。如果换成 CAN FD同样的包大约能压缩到 20 秒以内这就是为什么新一点的域控制器都在往 FD 上转。但对我们这个项目来说换 FD 意味着换芯片、换收发器、换整条总线的拓扑设计成本上不划算。所以策略是传输协议栈按 CAN FD 兼容的方式写底层驱动保持经典 CAN将来换平台时上层协议基本不用动。至于以太网刷写那是另一个量级的架构DoIP 要完整的 TCP/IP 栈TC275 这个资源做起来性价比太低。选型的核心逻辑是能用简单方案解决的不要为了技术先进性上复杂方案产线上多一个环节就多一个故障点。2. 分区表和启动流程Bootloader 的骨架2.1 Flash 分区怎么切这一步看起来简单其实最容易埋雷。TC27x 的 PFlash 是按 Bank 和 Sector 两级组织的写入的最小单位是一个页擦除的最小单位是一个逻辑扇区。具体的页大小和扇区大小一定要去你手上那颗型号的 Flash 章节确认我见过不同型号差一个数量级的情况。我这份分区表是按 4MB 空间切出来的特意让每一块的起始地址都落在扇区边界上区域起始地址大小擦写策略Bootloader0xA0000000256KB出厂后永不擦除App A0xA00400001.5MB刷写时擦App B0xA01C00001.5MB备用槽A/B 回滚用标定与参数0xA0340000768KB按标定流程单独擦Boot 参数区DFlash0xAF0000008KB存有效标志、指纹、重试计数这里有两个设计决定值得解释。第一个是A/B 双槽。单槽刷写的问题是擦除 App 的那一刻车上是没有任何可运行程序的一旦这时候断电ECU 就是块砖。双槽的做法是 App 在 A 槽跑的时候新固件往 B 槽写写完校验通过改一下参数区里的当前有效槽标志复位后从 B 槽启动。整个过程里始终有一份完整可运行的 App风险低得多。代价是 Flash 直接少了一半但 4MB 的片子上装 1.5MB 的 App还是撑得住的。第二个是参数区放在 DFlash 而不是 PFlash。刷写状态、重试计数这类数据需要频繁更新放在 PFlash 里意味着每次都要擦一个扇区寿命和速度都不划算。DFlash 就是为这种场景设计的刷新粒度小得多。但注意一点DFlash 不是无限寿命的状态写入要做频率控制别每一帧数据都去写一次。2.2 上电之后的启动流程AURIX 复位之后只有 CPU0 在跑CPU1 和 CPU2 停在 halt 状态要由 CPU0 通过寄存器把它们放出来。这个特性和很多双核 MCU 不一样第一次接触容易蒙。Bootloader 阶段我通常不释放 CPU1/CPU2就让它们停着等到跳 App 之前再由 App 自己的启动代码去释放——这样职责清晰也不会出现 Bootloader 改了外设、App 起来一脸茫然的情况。完整的上电流程大概长这样上电复位CPU0 从 Boot ROM 执行跳到 PFlash 里 Bootloader 的启动代码。启动代码做最基础的自检时钟初始化、基本 RAM 检查、看门狗配置。读 DFlash 参数区看App 有效标志和当前有效槽。标志有效且校验通过就跳 App标志无效或校验失败就停在 Bootloader 里等诊断请求。如果停在 Bootloader先给一段等待窗口我设的 500ms窗口内没收到诊断请求就直接尝试跳 App避免正常上电也被诊断流程拖慢。第 5 步这个等待窗口是被逼出来的。最开始我写的是没有有效 App 就一直等诊断结果发现正常量产件上电后也要在 Bootloader 里耗着等 S3 超时才跳走整车下电上电的体验很差。改成短窗口 主动跳转之后正常上电的启动时间从 5 秒压到了 600 毫秒以内。2.3 从 Boot 跳到 App 的几个硬骨头跳转这件事新手最容易写成一句函数指针调用就完事然后 App 跑起来各种玄学问题。TriCore 上有几个东西必须在跳转前处理干净。第一是BIV 寄存器。TriCore 的中断向量表和 ARM 那种固定在地址 0 的不一样它由一个叫 BIV 的寄存器指定基地址。Bootloader 里配置过 BIV如果不重置就跳过去App 里发生中断时会跳到一个已经不存在的向量表上症状是一有中断就跑飞。做法是跳转前把中断全部关掉、清掉挂起的中断标志让 App 的启动代码重新设置 BIV。第二是CSA 链表。TriCore 的函数调用和中断上下文不是存在传统栈里的而是存在 DSPR 里的一条叫 CSA 的链表中由 PCXI、FCX、LCX 这几个寄存器维护。Bootloader 运行时这条链已经用了不少节点直接跳过去的话App 起来后接着用这条旧链容易出现莫名其妙就复位。规范做法是跳到 App 的 Cstart 而不是 main让 App 的启动代码把整条链重新初始化一遍。第三是看门狗。AURIX 上安全看门狗不能彻底关掉只能改超时时间。擦 Flash 的时候 CPU 会被 stall喂狗必须靠定时器中断或者独立的核来做不能指望主循环里那句喂狗。我这里的做法是擦写期间把安全看门狗的超时时间放长同时用一个定时器中断按时喂擦完再改回来。第四是EndInit 保护。AURIX 上很多关键寄存器受 EndInit 保护写之前必须用密码解除。我第一次写 Flash 控制寄存器完全不生效查了半天才发现是这个。密码通过 iLLD 里那两个接口拿一个取 CPU 看门狗密码一个取安全看门狗密码用完记得重新上锁。3. CAN 驱动与 ISO-TP把诊断报文收进来3.1 MultiCAN 的节点和 Message Object 规划TC275 的 MultiCAN 支持把不同 Node 分配给不同 CPU中断也可以路由到指定核。既然 Bootloader 只在 CPU0 跑我就把 CAN0 整个划给 CPU0 专用其余 Node 留给 App 阶段用。Message Object 的分配上有个经验不要把每个要收的 CAN ID 都单独配一个 MO那样 MO 很快就不够用了而且改 ID 就得重配。更好的做法是利用 MultiCAN 的 ID 掩码过滤把一段连续的 ID 一次性收进同一个 MO配合 FIFO 模式让软件层去区分具体是哪个 ID。方向CAN ID类型用途MO 配置收0x7E0标准帧物理寻址诊断请求MO0单 ID 精确过滤收0x7DF标准帧功能寻址广播请求MO1单 ID 精确过滤发0x7E8标准帧诊断响应MO2发送队列关于CAN 报文里的 ID 代表什么这里可以顺手说清楚11 位 ID 不是地址它同时承担两个职责——标识这条报文是什么以及决定仲裁优先级。ID 数值越小优先级越高。诊断常用的 0x7E0 系列属于中等优先级如果总线上有一堆 0x1xx 的实时控制报文在跑诊断帧会被持续压制表现为偶发响应超时。这也是为什么刷写应该走独立诊断口或者独占总线。3.2 位定时参数怎么算包括那个 SJW位定时算错是 CAN 通信最隐蔽的故障来源之一因为低速短距离下算错也能跑一上负载就开始随机错误。我把计算过程完整写一遍。先确定 CAN 控制器的输入时钟。这颗片子上经过分频后可以拿到 40MHz 的 CAN 时钟。目标波特率 500kbps也就是每位 2000ns。第一步算时间份额选分频系数为 4那么一个 tq 4 / 40MHz 100ns。第二步算每位需要多少个 tq2000ns / 100ns 20 tq。第三步分配段位时间 同步段 时间段 1 时间段 2 1 TSEG1 TSEG2 20。采样点希望落在 80%也就是 (1 TSEG1) / 20 0.8得到 TSEG1 15TSEG2 4。验证一下1 15 4 20正确。第四步定 SJW。SJW 是重新同步跳转宽度用来吸收振荡器偏差和位填充造成的相位抖动取值不能超过 TSEG2。我取 3留一点余量。参数取值说明CAN 时钟40 MHz分频前分频系数4tq 100 ns每位 tq 数20500 kbpsTSEG115传播段 相位缓冲段 1TSEG24相位缓冲段 2采样点80%(115)/20SJW3不超过 TSEG2提示采样点位置不是随便定的。如果你要和别人已有的 ECU 挂在同一条总线上务必查一下对方的采样点设置。我用 80%对方用 87.5%两边都能单独通信但一上长线就开始间隔性出错这种问题查起来非常痛苦。3.3 ISO-TP 分包重组UDS 的数据通道UDS 报文最长可以到 4095 字节CAN 一帧最多 8 字节中间必须有一层传输协议来分包这就是 ISO-TP也就是 ISO 15765-2。四种帧类型一定要背下来单帧 SF一帧装得下首字节高 4 位是 0低 4 位是数据长度。首帧 FF多帧数据的开头首两字节是 0x1 加 12 位总长度。连续帧 CF后续数据首字节高 4 位是 2低 4 位是序号从 1 开始循环。流控帧 FC接收方告诉发送方你可以发几帧、帧间隔多少。下位机实现里接收方向相对简单因为上位机发请求一般不会很长发送方向才是重点因为响应里可能有几百字节的数据比如读一组 DID。我踩过的一个坑是流控帧里的 BS 和 STmin 必须严格按收到值执行不能自己拍脑袋改。有一次为了提速我在发送侧无视了上位机给的 STmin结果上位机的接收缓冲溢出直接丢帧表现为刷写刷到一半报长度错误。STmin 的处理还有个细节标准规定 0x00 到 0x7F 表示毫秒0xF1 到 0xF9 表示 100 到 900 微秒。很多 MCU 的定时器精度做不到微秒级我的做法是把 0xF1 到 0xF9 一律按 1 毫秒处理虽然慢一点但绝对不会出错。刷写的时候上位机一般会给 STmin 0那就退化成发完一帧立刻发下一帧靠总线本身的位时间来自然间隔此时驱动要保证发送请求不丢。4. UDS 服务裁剪与 Flash 驱动下载4.1 必须实现的服务清单UDS 定义了二十多个服务但 Bootloader 里真正必须实现的没那么多。我把这份清单按优先级列出来加粗的是不实现就跑不起来的SID服务子功能必要性说明0x10诊断会话控制0x01/0x02/0x03必须进编程会话的前提0x11ECU 复位0x01/0x03必须刷完跳 App 的触发手段0x27安全访问0x01/0x02必须防误刷的第一道门0x34请求下载—必须告知地址和长度0x36数据传输—必须真正的数据搬运工0x37请求退出传输—必须结束传输并回校验结果0x31例程控制0x01/0x02/0x03必须擦除、校验、依赖检查0x3E会话保持0x00必须否则 S3 超时踢出编程会话0x22按标识读数据—强烈建议指纹、版本号读取0x85DTC 设置控制0x01/0x02建议刷写期间抑制故障码0x28通信控制0x00/0x01/0x03建议刷写期间关普通通信0x14清除故障码—建议刷完清一次0x19读取故障码0x02建议产线会读刷写失败记录0x2E按标识写数据—可选写指纹信息关于 0x19 服务这里多讲一句。刷写失败要在 ECU 里留下痕迹产线读 DTC 就是为了区分这个件是刷写失败了还是这个件本身有硬件故障。我的做法是在 Bootloader 参数区记录最近三次刷写的结果状态App 起来之后把它转成对应的故障码。这样即使 ECU 已经跳到 App诊断仪照样能读到历史。4.2 27 服务没有 HSM 的芯片上怎么兜底TC275 这颗片子没有独立的硬件安全模块这一点在方案评审时被人问过很多次。没有 HSM 意味着种子密钥算法只能跑在主核的普通代码里理论上只要拿到 Flash 读出内容就能反推出密钥。这是硬件决定的不是实现问题。那怎么办我的应对策略是分层第一层安全访问本身还是要做的它能拦住 90% 的误操作和非授权工具。种子由下位机用真随机数发生器或者至少是一个足够好的伪随机序列生成每次会话都不一样密钥算法用对称加密密钥不硬编码在代码里而是放在 DFlash 的一个受保护区域配合 Flash 读保护。第二层靠调试口锁定兜底。量产件出厂时把调试接口锁掉这样别人拿不到 Flash 内容密钥就推不出来。开发件保留调试口方便排查。这个切换要在产线流程里做成一个明确的工序。第三层靠刷写指纹做追溯。每一次成功的刷写在参数区留下时间戳和固件指纹出问题能查是谁什么时候刷的。具体到协议层安全等级我用 0x01请求种子是子功能 0x01发送密钥是 0x02。连续三次密钥错误就锁定需要等一段延时才能重试。这个延时一定要做在 ECU 侧而不是上位机侧否则暴力破解工具直接无视上位机的等待逻辑就行。4.3 Flash 驱动为什么要拷到 RAM 里跑这是整个项目里最反直觉的一点理解不了它后面的代码就写不对。Flash 的擦除和写入是通过一组控制寄存器完成的而这些寄存器需要 CPU 去读写。问题在于当你正在擦除某个 PFlash 扇区时如果执行代码也在同一个 Bank 里CPU 取指就会 stall程序名义上卡住了。AURIX 的 PFlash 分了多个 Bank支持在一个 Bank 擦写时从另一个 Bank 取指这个特性叫 Read-While-Write。理论上可以利用这个特性直接把擦写代码放在 Flash 里跑但实际工程里大家还是倾向于把 Flash 驱动做成一个独立的二进制镜像通过 34/36/37 服务下载到 RAM 再执行。这么做的理由有三个。一是安全RAM 里的驱动只在这一个刷写会话里存在刷完就没了不会污染 Flash 布局。二是可替换不同批次的芯片 Flash 控制器行为可能有微小差异驱动独立成镜像之后只要换一个 bin 文件Bootloader 本体不用重编。三是规避依赖驱动里不能调用 Bootloader 的任何函数它必须是完全自包含的这样才能保证在任何地址执行都正常。具体的做法是把 Flash 驱动的源码单独建一个工程编译时指定链接到 RAM 地址段我用 DSPR 的高地址区产出一个纯二进制的 bin。上位机刷写流程的阶段一就是把这个 bin 通过 UDS 下载进去然后用 0x31 服务触发它执行。注意Flash 驱动里绝对不能有对 Bootloader 全局变量、常量表、字符串的引用。我曾经因为驱动里 printf 了一个字符串常量导致整个镜像的定位信息错乱下载进 RAM 之后一调用就跑飞查了两天才发现。5. 刷写实操从上位机脚本到 App 跑起来5.1 上位机用 Python 搭一套刷写脚本产线上当然用 CANoe 或者专用刷写工具但开发阶段用 Python 更灵活改一行就能重跑。我用的组合是 python-can 负责报文收发isotp 负责 ISO-TP 层udsoncan 负责 UDS 层三个库各司其职装起来就三条 pip 命令。import can import isotp import udsoncan from udsoncan.connections import PythonIsoTpConnection from udsoncan.client import Client from udsoncan import MemoryLocation # 1. 物理层我用的是 PCAN 盒子也可以换成 socketcan 或者 vector bus can.interface.Bus(interfacepcan, channelPCAN_USBBUS1, bitrate500000) # 2. 传输层参数这几个值要和下位机对得上 tp_params { stmin: 1, # 连续帧最小间隔毫秒 blocksize: 8, # 每轮流控允许的帧数 ll_data_length: 8, rx_flowcontrol_timeout: 1000, # N_Bs rx_consecutive_frame_timeout: 1000, # N_Cr } addr isotp.Address(isotp.AddressingMode.Normal_11bits, txid0x7E0, rxid0x7E8) stack isotp.CanStack(busbus, addressaddr, paramstp_params) conn PythonIsoTpConnection(stack) # 3. 诊断层 with Client(conn, request_timeout5) as cli: cli.change_session(0x03) # 先到扩展会话 cli.change_session(0x02) # 再进编程会话 seed cli.request_seed(0x01) # 拿种子 key calc_key(seed) # 本地算密钥 cli.send_key(0x02, key) # 发密钥 # ... 后续下载 Flash 驱动、擦除、写入这段代码里有两个地方值得说。第一是STmin 和 BS 的取值必须和下位机的实现匹配我这边下位机是严格按收到的流控帧执行所以上位机给多少它就照做不会自作主张。第二是会话切换要走两步很多实现从默认会话直接跳到编程会话会返回否定响应稳妥的做法是先到扩展会话再到编程会话。5.2 完整刷写时序一步都不能省把整个过程按时间顺序摊开是这样的进入扩展会话0x10 03读一遍当前版本和指纹0x22。安全检查0x27拿种子、算密钥、发密钥。切换到编程会话0x10 02。关掉普通通信和 DTC 记录0x28 03、0x85 02。下载 Flash 驱动到 RAM0x34 / 0x36 / 0x37。用 0x31 触发擦除例程例程 ID 0xFF00擦除目标槽位。下载 App 固件0x34 / 0x36 / 0x37分块传输。用 0x31 触发校验例程0xFF01下位机自己算一遍 CRC 比对。用 0x31 触发依赖检查例程0xFF02确认版本兼容。写指纹和有效标志到 DFlash。ECU 复位0x11 01从新槽位启动。第 6 步到第 8 步这三个例程 ID 是 ISO 14229-1 附录例子里给的约定值很多 OEM 会改成自己的编号别直接照抄一定按你们的诊断规范来。我见过有人拿着别家的规范刷自己的件卡在例程不支持的否定响应上查了一整天。另外第 7 步有个容易被忽略的点34 服务里的地址和长度字段格式不是固定的地址和长度各占几个字节由请求里的一个参数决定常见是 4 字节地址加 4 字节长度但也有用 3 字节的。上位机算错字节数下位机解析出来的地址就是乱的表现是写进去了但读出来全不对。我建议在 Bootloader 里对长度字段做严格的范围检查超出分区边界直接返回请求超出范围的否定响应。5.3 下位机的擦写骨架下位机这部分重点是三个动作擦一个扇区、写一个页、校验。写页的顺序不能乱AURIX 的 PFlash 带 ECC一个页必须一次性把所有字都装配完再触发写入中途去写别的页会破坏 ECC 结构。骨架大致是这样#include IfxFlash.h #include IfxScuWdt.h static uint16 g_safetyPwd; /* 擦除一个扇区sectorAddr 传扇区首地址 */ boolean Boot_EraseSector(uint32 sectorAddr) { g_safetyPwd IfxScuWdt_getSafetyWatchdogPassword(); IfxScuWdt_clearSafetyEndinit(g_safetyPwd); IfxFlash_eraseSector(sectorAddr); IfxScuWdt_setSafetyEndinit(g_safetyPwd); /* 擦除是异步的必须轮询等到控制器不忙 */ return IfxFlash_waitUnbusy(0, IfxFlash_FlashType_P0); } /* 写一个页要求 4 字节对齐且该页必须是已擦除状态 */ boolean Boot_WritePage(uint32 pageAddr, const uint8 *data, uint32 len) { uint32 i; if ((len % 4) ! 0) { return FALSE; /* 页写入必须按字对齐 */ } g_safetyPwd IfxScuWdt_getSafetyWatchdogPassword(); IfxScuWdt_clearSafetyEndinit(g_safetyPwd); IfxFlash_enterPageMode(pageAddr); for (i 0; i len; i 8) { uint32 low data[i] | (data[i1] 8) | (data[i2] 16) | (data[i3] 24); uint32 high data[i4] | (data[i5] 8) | (data[i6] 16) | (data[i7] 24); IfxFlash_loadPage(pageAddr, low, high); } IfxFlash_writePage(pageAddr); IfxScuWdt_setSafetyEndinit(g_safetyPwd); return IfxFlash_waitUnbusy(0, IfxFlash_FlashType_P0); }接口名字和参数按你手上 iLLD 的版本核对一遍不同版本之间小有出入但整体思路是一致的先解保护再操作再等控制器不忙最后重新上锁。少任何一步都会出问题。还有一个经验擦除之后不要拿读出来全是 0xFF当擦除成功的判据。带 ECC 的 Flash 在页被正式写之前读回来的内容不一定是你期望的值甚至可能报 ECC 错误。用官方的擦除验证接口或者干脆自己算一遍校验和比对比目测字节可靠得多。5.4 总线负载率算一笔账别把诊断线跑爆刷写之前我一直觉得就一条诊断报文能占多少带宽直到第一次实测发现总线负载率飙到 95% 以上。算一遍就明白了。500kbps 下一个标准 8 字节数据帧的位时间构成是帧起始 1 位、仲裁段 12 位、控制段 6 位、数据段 64 位、CRC 段 15 位、应答段 2 位、帧结束 7 位、帧间隔 3 位合计 110 位再算上最坏情况约 20% 的位填充按 120 位估。每秒可传 500000 / 120 约等于 4166 帧。ISO-TP 的连续帧每帧带 7 个有效字节所以理论吞吐 4166 × 7 约等于 29.2KB/s。实际扣掉流控帧、UDS 服务头、最后一帧装不满的尾巴能稳定跑到 18 到 22KB/s。项目数值备注波特率500 kbps经典 CAN单帧位时间约 120 位含位填充余量峰值帧率约 4166 帧/秒理论值单帧有效载荷7 字节ISO-TP 连续帧理论吞吐约 29.2 KB/s满载实测吞吐18 ~ 22 KB/s含各类开销2MB 固件传输时间约 95 ~ 115 秒纯传输含擦除校验总耗时约 150 ~ 180 秒实际产线数据结论很清楚刷写期间这条总线基本就是被诊断报文占满了别的节点想发报文会被仲裁机制持续压制。所以刷写一定走独立诊断口或者在产线上用专门的刷写工位不要和整车功能总线混在一起。如果实在避不开就把流控帧的 BS 设成较小的值中间插一些空闲时间让其他节点有机会发报文代价是刷写时间拉长。6. 踩坑实录与排查速查表6.1 现象、原因、处理调试过程中攒下来的一批典型问题整理成表遇到类似症状可以按图索骥。现象最可能的原因处理方式27 服务一直返回条件不满足没先进扩展会话或当前会话不允许先切 0x10 03再切 0x10 02发送响应后上位机收不到发送侧 ID 或 ISO-TP 层配置错误抓总线确认实际发出去的 ID刷到一半报块序号错误连续帧序号没循环处理检查 CF 序号是否从 1 到 15 后回 1单帧收发正常多帧必失败流控帧参数没按收到值执行核对 BS 和 STmin 的解析逻辑擦除成功写入后读出来不对页没一次性装配完整ECC 破坏检查写页前是否所有字都 load 完刷完跳 App 立刻复位BIV 未重置中断向量漂移跳转前清中断和 BIV上电偶发不启动App 有效标志写入和断电时序竞争标志写入用双副本加校验通信偶发错误负载越高越频繁采样点和对方不一致或 SJW 过小统一采样点SJW 留够余量第一次写 Flash 寄存器无效EndInit 保护未解除写前用密码解除写完重新上锁编程会话里响应突然变慢下位机没有及时发 0x78长耗时操作前先发响应挂起这里重点说两个。第一个是0x78 响应挂起。擦除一个扇区、校验一大块数据这些操作耗时可能超过 P2Server 的时间上限一般 50 毫秒。这时候下位机必须先回一个否定响应响应码是 0x78告诉上位机我还在处理你再等等把计时器切到 P2*Server一般 5000 毫秒。如果没有这个机制上位机在 50 毫秒后就判超时了而下位机还在勤勤恳恳地擦 Flash等你擦完再发响应那边早就放弃了。这是个纯靠协议约定解决时序问题实现起来就几行代码但不写就一定会出问题。第二个是App 有效标志的写入顺序。跳 App 的判据是参数区里一个标志这个标志写早了万一下载其实没完成上电就跳到一份残缺的 App 上写晚了万一下一次断电前没写成又退回了旧 App。我的做法是校验通过之后写标志标志用两份互为补码的副本存储读的时候两份都读出来比对不一致就按无效处理。看似冗余但断电恰好发生在写入那几毫秒的概率虽小量产后总会碰上。6.2 不小心刷成砖了怎么救这个必须提前准备好不然真出事的时候只能换件。AURIX 的可用手段是启动模式选择。芯片上电时会读一组启动模式相关的配置如果配置成从内部 Flash 启动那就直接跑上面的程序如果配置成从别的接口启动就能绕过 Flash。具体到你这个板子有哪些模式、怎么触发一定去看启动章节和板子原理图。我的做法是在开发阶段就留一条物理的强制进 Bootloader路径比如一个跳线或者特定的引脚组合。板子上电时检测这个状态如果被拉住了无论 App 有效标志是什么都强制停在 Bootloader 里等诊断绝不跳 App。这样只要硬件还能上电就一定能刷回来。工装上的准备也很重要。Lite Kit 上板载调试器插上 USB 就能用调试工具直接擦 Flash这是最省事的救砖手段。但如果你的量产件没有引调试口就只能在 Bootloader 里多留几条后路比如支持功能寻址的广播进编程会话这样即使诊断 ID 配错了也有机会救回来。注意救砖路径不要做得太好用。我见过有人把收到某个特殊诊断请求就无条件擦除 App做成了救砖机制结果产线上误触发一批件全被擦了。救砖通道要有明确的前置条件最好配合物理状态。6.3 几个反直觉的细节最后列几个我踩过、但常规文档里不太会写的点。第一个擦除后的内容不等于 0xFF。带 ECC 的 Flash 在页被正式编程之前读出来的内容是不确定的甚至可能触发 ECC 错误告警。这不是擦除失败是正常的物理状态。别用它当判据。第二个如果你在产出代码里用了 Flash 驱动目录之外的任何文件链接大概率会出问题。因为 Flash 驱动的镜像需要保证在任何地址都能执行任何绝对地址引用都会破坏可重定位性。这一点在编译和链接选项上要专门配置不能沿用普通工程。第三个擦写时间不是线性的。同样的扇区擦第一个和擦第八个耗时可能差别不小因为控制器内部有编程和擦除的时间约束。产线节拍评估时一定要按实测最坏值算不能用平均值乘数量我吃过这个亏理论算出来 90 秒实测峰值到了 130 秒。第四个会话保持一定要做。编程会话的 S3 超时一般是 5000 毫秒上位机在此期间不发任何报文ECU 就会退回默认会话接下来的一切操作都会返回条件不满足。稳妥的做法是上位机每 2 秒发一次 0x3E 00。别把间隔卡到 4.9 秒总线一抖动就超时了。7. 往量产走几个工程化上的考虑7.1 防盗刷和指纹管理开发阶段和量产阶段的要求完全不同。开发阶段我们希望越透明越好量产阶段则要求非授权工具绝对不能刷进去。除了前面说的安全访问和调试口锁定还有两件事要做。第一是固件签名校验。上位机刷进来的固件除了 CRC还要带一段由厂商私钥生成的签名Bootloader 用烧在芯片里的公钥验签。这样即使有人绕过了安全访问也刷不进自制的固件。第二是指纹唯一化。每一件的刷写时间、固件版本、刷写次数都要写进 DFlash产线可以通过诊断读取这些信息售后也能据此判断是不是原厂刷写。这两个机制一定要在 Bootloader 的第一版就设计进去因为后期往已经量产的件上加等于所有件都得重新刷一遍。7.2 版本管理和诊断数据库诊断数据库CDD 或者 ODX 文件和代码必须同源管理。我见过太多项目是代码改了一个 DID 的地址数据库文件没更新产线的诊断仪拿着旧数据库去读读出来全错然后一堆人开始怀疑下位机有 bug。我的做法是把 DID 定义、例程 ID、否定响应码这些全部集中到一个头文件里两边都从这个头文件生成。代码编译时引用它诊断数据库生成脚本也读它从源头上避免不一致。这个投入在项目初期看着有点多余到项目后期会省下大量扯皮时间。7.3 OTA 和 Bootloader 到底什么关系经常有人问我已经做了 OTA还需要 Bootloader 吗。这两件事根本不是同一个层面的东西。OTA 解决的是怎么把固件包从云端送到车端它关心的是通信链路、断点续传、包的完整性。Bootloader 解决的是拿到包之后怎么把包写进 Flash它关心的是擦写、校验、回滚。OTA 的最后一公里永远要落到 Bootloader 上。车端的 OTA 模块下载完固件包最终还是要通过诊断协议把数据交给 Bootloader让它去执行擦写。区别只在于这条链路是走车内总线还是走本地接口。所以一个设计良好的 Bootloader天然就能支撑 OTA不需要为 OTA 单独再做一套刷写逻辑。反而要注意的是OTA 场景下断电的概率比产线高得多因为车可能在任意时刻下电。这就要求 A/B 双槽和有效标志的容错逻辑做得更扎实最好在每次写入关键数据之后都做一次掉电一致性检查。这套东西从空白工程到在板子上完整跑通一遍刷写我大概花了三周其中一半时间花在查 CAN 通信的偶发错误和 Flash 写入的细节上。要说最值得分享的一条经验在动手写 UDS 之前先把 CAN 层调通并且用示波器确认采样点和电平完全正常。我一开始图快CAN 收发还没完全稳定就开始写协议栈结果后面每一个异常我都要分成是协议问题还是物理层问题来排查效率极低。把底层一次做扎实上层调试会顺很多。另外一个小心得Flash 驱动的镜像最好在项目一开始就独立出来编译哪怕当时只有一个空函数。等写到后面再拆分链接脚本和编译选项的坑会让你怀疑人生。