2. AURIX芯片家族与生产刷写对象

在产线刷写与追溯体系中，第一步不是连接工具，而是明确“刷写对象到底是谁”。AURIX 家族从 TC2xx 到 TC3xx 再到 TC4xx，内核数量、存储容量、安全架构和刷写接口都在演进，如果只按“AURIX 都一样”的思路处理，很容易在 PFLASH 分区、HSM 固件或 UCB 配置上踩坑。本节把芯片家族、Flash 存储结构、HSM 与 UCB 四个概念串成一条线，帮助你在实际刷写前建立正确的对象模型。

一、TC2xx / TC3xx / TC4xx 的定位差异

TC2xx 是 AURIX 的第一代多核架构，典型如 TC275、TC277，常用于车身、底盘和工业控制。它采用 TriCore 内核加外设的经典结构，PFLASH 容量一般在 1MB～4MB 量级，HSM 为可选配置，部分型号没有独立 HSM 核。TC3xx 是当前量产主力，如 TC375、TC387、TC397，内核数量从 1 到 6 个不等，PFLASH 可达 8MB～16MB，HSM 基本成为标配，且支持更完整的 Secure Boot 与刷写鉴权。TC4xx 面向更高安全等级和更高算力场景，引入更复杂的多核集群、更大的 SRAM 和更严格的 HSM 隔离，刷写时对 UCB 和 HSM 的依赖更强。

对生产刷写而言，这三代最关键的差异不在主频，而在三件事：PFLASH 分区方式、HSM 是否参与启动校验、UCB 中刷写相关配置项的数量与含义。TC2xx 的刷写流程相对简单，很多型号可以只刷 PFLASH 主体；TC3xx 开始，HSM 固件和 UCB 配置往往需要单独处理；TC4xx 则要求刷写工具链同时理解 HSM 与 UCB 的联动关系。

二、Flash 存储结构：PFLASH、DFLASH 与 OTP

AURIX 的片上非易失存储通常分为三类。PFLASH（Program Flash）存放用户程序、标定数据和启动代码，是刷写的主要对象，按扇区（Sector）或逻辑块组织，擦除粒度通常为 1KB～4KB，写入前必须擦除。DFLASH（Data Flash）用于存放频繁更新的数据，如 EEPROM 模拟、故障码和标定参数，擦写寿命更高，但容量较小。OTP（One-Time Programmable）区域只能写一次，常用于存放芯片唯一 ID、生命周期状态和部分安全配置，生产刷写中一般只读不写。

以 TC3xx 为例，PFLASH 常被划分为多个逻辑块，其中一部分用于存放 HSM 固件，一部分用于用户程序，还有一部分可能保留给 Bootloader。刷写时如果只更新用户程序，必须确认 HSM 固件和 UCB 不被误擦；如果整片擦除，则 HSM 固件和 UCB 需要重新写入。DFLASH 通常不参与主程序刷写，但在追溯体系中，它可能保存刷写计数、版本号和产线工位信息，需要在刷写后单独校验。

三、HSM：刷写鉴权与安全启动的核心

HSM（Hardware Security Module）是 AURIX 内部独立的安全核，拥有自己的 ROM、RAM 和 Flash 区域。在生产刷写中，HSM 主要承担三个角色：第一，验证刷写固件的签名，只有通过鉴权的固件才能写入 PFLASH；第二，参与 Secure Boot，芯片上电后由 HSM 校验启动代码的完整性；第三，管理密钥和生命周期状态，防止未授权调试或回读。

实际产线中，HSM 固件本身也需要刷写。TC3xx 的 HSM 固件通常以独立镜像形式提供，刷写顺序一般是先刷 HSM 固件，再刷用户程序，最后配置 UCB。如果顺序颠倒，可能出现 HSM 未就绪导致用户程序无法启动的情况。此外，HSM 的调试口在量产阶段通常会被关闭，刷写工具必须通过 HSM 提供的安全通道进行通信，而不是直接访问 TriCore 调试接口。

四、UCB：芯片配置的“最后一道开关”

UCB（User Configuration Block）是 AURIX 中一组特殊的非易失配置块，位于 PFLASH 的特定区域，用于存放启动模式、时钟配置、调试保护、HSM 使能和刷写保护等参数。UCB 的特点是“写一次、需校验、可锁定”，每个 UCB 通常有多个副本，写入后通过比较副本一致性来判断是否生效。生产刷写中，UCB 的配置直接决定芯片能否正常启动、能否再次刷写、能否被调试。

常见的 UCB 配置项包括：BMHD（Boot Mode Header）决定启动地址和启动模式；PROCON（Protection Configuration）设置 PFLASH 和 DFLASH 的读写保护；HSMCFG 控制 HSM 使能和启动方式；OTP 区域中的生命周期状态决定芯片处于开发、量产还是报废阶段。刷写时如果 UCB 配置错误，芯片可能直接变砖，因此产线通常要求先刷 UCB 再刷程序，并在刷写后立即回读校验。

五、生产刷写中的对象确认清单

在真正下发刷写任务前，建议按以下顺序确认对象：第一，确认芯片型号和硅版本，不同版本的 UCB 布局和 HSM 固件可能不兼容；第二，确认 PFLASH 分区表，明确用户程序、HSM 固件和标定区的地址范围；第三，确认 HSM 是否使能，如果使能，需要准备对应的签名密钥和刷写通道；第四，确认 UCB 当前状态，特别是 BMHD 和 PROCON 是否已被锁定；第五，确认 DFLASH 中是否有需要保留的追溯数据。

六、示例：TC3xx 刷写对象参数表

下表给出一个 TC3xx 典型项目的刷写对象示例参数，用于说明各区域在产线脚本中如何被识别和校验。表中地址和容量为教学示例，实际项目需以芯片数据手册和项目分区表为准。

这张表的意义在于把“刷什么、刷到哪里、怎么确认刷成功”三件事绑定在一起。产线脚本通常按对象逐项执行，每完成一项就记录结果，而不是等全部刷完再统一校验。这样一旦某一项失败，可以快速定位是 HSM 鉴权问题、PFLASH 编程问题还是 UCB 配置问题。

七、常见误区与判断依据

第一个误区是“只刷 App 就够了”。在 HSM 使能的 TC3xx 上，如果 HSM 固件版本与 App 不匹配，Secure Boot 会失败，芯片表现为反复复位或停在启动阶段。判断依据是读取启动状态寄存器或通过 HSM 日志确认鉴权结果。第二个误区是“UCB 可以反复写”。实际上 UCB 写入后需要锁定，锁定后不可再改，因此产线必须在写入前确认配置值。第三个误区是“DFLASH 不影响启动”。如果 DFLASH 中保存了启动参数或安全标志，擦除后可能导致启动异常，刷写前应确认是否需要保留。