2. ST Stellar 硬件与软件基础
在开始做 XCP 标定之前，必须先弄清楚一件事：标定工具最终“碰到”的到底是什么。它并不是直接读写某个变量名，而是通过一条从 PC 到 ECU 内部存储器的完整链路，去访问 Stellar 芯片里的 RAM、Flash 以及外设寄存器。这条链路的每一段——内核、总线、外设、AUTOSAR 软件层、MCAL 驱动、通信控制器——都会影响标定能否成功、速率能到多少、以及哪些量可以被观测。本节把这条链路拆开讲清楚，为后续 XCP 配置和 A2L 生成打基础。
Stellar 系列的内核与外设资源
ST 的 Stellar 系列是面向汽车域控制器与区域控制器（Zonal ECU）的 MCU 家族，典型成员如 Stellar P、Stellar G、Stellar E。它们普遍采用多核架构：以 Arm Cortex-M7 作为实时应用核（常见配置为锁步双核，用于 ASIL-D 安全任务），并集成 Cortex-M4 或 GTM（Generic Timer Module）等用于特定功能。对 XCP 标定而言，需要重点关注三类资源。
第一是存储器资源。Stellar 内部通常包含大容量嵌入式 Flash（例如 8 MB 级别，用于代码与标定数据）、多块 SRAM（例如 1 MB 以上，分布在不同的电源与时钟域），以及若干带 ECC 的 RAM 区域。标定量的“当前值”一般放在 RAM 中，而“默认值/标定页”存放在 Flash 的标定段（Calibration Segment）里。XCP 的 RAM 页切换、Flash 编程都依赖这些区域的物理划分。
第二是通信外设。Stellar 集成多路 CAN FD 控制器（如 M_CAN 兼容模块）、以太网 MAC（支持 100/1000 Mbps，部分型号带 TSN 与交换机）、以及 LIN、FlexRay 等。XCP 在 Stellar 上最常用的传输层就是 CAN FD 和以太网（UDP/TCP），前者适合中小数据量、确定性要求高的场景，后者适合高带宽测量（如高速采样波形上传）。
第三是调试与追踪资源。Stellar 支持 DAP/JTAG 调试接口和 Aurora/HSSTP 高速追踪，这些通道在开发阶段可用于程序下载和指令级追踪，但它们与 XCP 是两条独立的路径：XCP 走的是应用层通信外设，不需要调试器在线，这也是量产车标定必须依赖 XCP 的原因。
AUTOSAR 分层架构与标定量的位置
Stellar 上的软件通常按 AUTOSAR Classic Platform 组织，自上而下分为应用层（SWC）、运行时环境（RTE）、基础软件层（BSW）。BSW 又细分为服务层、ECU 抽象层（ECU Abstraction Layer）、微控制器抽象层（MCAL）和复杂驱动（CDD）。理解这个分层，关键在于知道“标定量”和“测量量”分别落在哪一层。
标定量（Calibration Parameter）本质上是应用层 SWC 或 BSW 模块中的常量/可写变量，例如发动机喷油脉宽查表、电机扭矩限值、PID 增益。它们通过 RTE 或直接由模块访问。XCP 要读写这些量，必须知道它们在内存中的地址和数据类型，这正是 A2L 文件描述的内容。测量量（Measurement Variable）则是运行时的观测量，如转速、电流、温度，通常来自 SWC 的输出端口或 BSW 的传感器采集结果。
XCP 模块本身在 AUTOSAR 中属于 BSW 的服务层组件（Xcp 模块），它通过 PDU Router（PduR）与通信栈交互，通过 Det、Dem 做诊断上报，通过 OS 做任务调度。也就是说，XCP 并不是“绕过 AUTOSAR”直接操作硬件，而是作为标准 BSW 模块被集成进整个协议栈。这一点决定了 XCP 的配置必须与 Com、PduR、CanIf/EthIf 等模块协同。
MCAL 与 ECU 抽象层：标定访问的底层通道
MCAL 是直接操作 Stellar 寄存器的驱动层，包含 Can、Eth、Adc、Pwm、Dio、Mcu、Port、Spi、Fls、Eep 等驱动。对标定而言，最相关的是 Can/Eth 驱动（负责 XCP 报文的收发）、Fls/Eep 驱动（负责标定数据的非易失存储）以及 Mcu 驱动（负责时钟与 RAM 初始化）。
ECU 抽象层位于 MCAL 之上，它把“某个具体外设”抽象为“ECU 的一个通道”。例如 CanIf 把多路 CAN 控制器统一为 CAN 接口，EthIf 把以太网 MAC 统一为以太网接口。XCP 通过 PduR 把 XCP PDU 路由到 CanIf 或 EthIf，再由它们调用 MCAL 驱动完成实际收发。这条路径是：Xcp → PduR → CanIf/EthIf → Can/Eth 驱动 → Stellar 外设寄存器。
需要特别注意的是，XCP 的传输层配置（如 CAN ID、波特率、以太网 IP/端口）并不在 Xcp 模块里直接写死，而是通过 PduR 的路由表和 CanIf/EthIf 的配置间接决定。因此当标定连接失败时，排查顺序应从物理层（线束、终端电阻）→ CanIf/EthIf 配置 → PduR 路由 → Xcp 模块，而不是一上来就怀疑 A2L。
标定相关的存储与通信硬件通道
把上面的内容落到具体硬件通道上，Stellar 上一条完整的 XCP 标定链路包含以下环节：PC 上的标定工具（如 CANape、INCA）通过 USB-CAN FD 盒或以太网接口发出 XCP 命令；命令经 CAN 总线或以太网到达 Stellar 的 M_CAN 控制器或以太网 MAC；MCAL 驱动把报文交给 CanIf/EthIf；PduR 根据配置把 XCP PDU 路由到 Xcp 模块；Xcp 模块解析命令后，通过内存访问接口读写目标地址的 RAM 或 Flash。
存储方面，标定数据通常分两处：RAM 中的“工作副本”用于实时读写，Flash 中的“标定段”用于掉电保存。XCP 的 DOWNLOAD 命令写 RAM，而要把标定结果固化，需要通过 XCP 的 PROGRAM 相关命令或由 Bootloader 配合 Fls 驱动擦写 Flash。Stellar 的 Flash 擦写以扇区为单位，标定段一般单独划分扇区，避免与代码段互相干扰。
从硬件到标定：一条命令的实际路径
假设标定工具要读取一个名为 EngSpd_Act 的测量量，其地址为 0x2040_1000，长度为 2 字节。工具发出 XCP 的 SHORT_UPLOAD 命令，命令帧经 CAN FD 以 500 kbps 仲裁段 / 2 Mbps 数据段发送。Stellar 的 M_CAN 控制器收到帧后触发中断，Can 驱动把报文放入接收缓冲区，CanIf 根据 CAN ID 判断这是 XCP 报文并上传给 PduR，PduR 查路由表后交给 Xcp 模块。Xcp 解析出命令码和地址，从 0x2040_1000 读取 2 字节，再按原路径反向封装成响应帧发回工具。整个过程在微秒到毫秒级完成，DAQ 模式下还可以周期性地自动上传，无需工具逐条请求。
如果这个地址在 A2L 中写错，或者 RAM 区域被 MPU 保护，Xcp 会返回 ERR_ACCESS_DENIED 或 ERR_OUT_OF_RANGE。因此标定工程师在集成阶段必须核对三件事：A2L 中的地址与链接脚本（Linker Script）一致、目标区域可读写、XCP 的地址映射配置正确。
存储与通信通道的选型建议
对于标定数据量小、实时性要求高的场景（如发动机台架），优先选 CAN FD：配置简单、确定性好、工具支持成熟。对于需要高速采样（如电机控制中的电流环波形，采样率 10 kHz 以上）的场景，选以太网 XCP：带宽高、支持 UDP 组播、DAQ 列表可以做得很大。Stellar 的以太网 MAC 通常支持硬件时间戳，配合 XCP 的时间同步机制，可以把多个 ECU 的测量数据对齐到同一时间基准。
存储方面，建议把标定段与代码段在 Flash 中物理隔离，并预留至少两个扇区用于 A/B 切换，避免擦写过程中掉电导致标定数据丢失。RAM 中的标定副本应在启动时从 Flash 加载，XCP 的 DOWNLOAD 只改 RAM，需要固化时再显式触发 Flash 编程。这样既保证了运行时的快速访问，又保证了掉电后的数据完整性。