AUTOSAR CanXcp传输链路详解：PDU离线队列与在线状态切换

ECU 完成 XCP 初始化后，测量标定工具仍可能收不到任何响应。一个常见原因不是 CAN 通道或 A2L 文件错误，而是 CanXcp 初始化后处于CANXCP_SET_OFFLINE：协议层可以产生响应，传输层却不会把帧发到总线。如果项目没有 CanSM，或者使用的状态管理器不会切换 CanXcp 的 PDU 模式，就必须由应用显式调用CanXcp_SetPduMode()进入在线状态。这个启动细节揭示了 CanXcp 的核心职责。XCP Protocol Layer 负责命令和会话语义，CanXcp 作为 XCP on CAN Transport Layer，负责在协议层与 AUTOSARCanIf之间搬运 CTO/DTO、管理发送确认、缓存暂时无法发送的帧，并通过主函数重试队列和触发 DAQ 发送。CanXcp 是硬件无关的传输协议实现，能够移植到不同 CAN 控制器，但微控制器、编译器和存储模型的组合很多，并不承诺在所有组合上都无需适配即可运行。这里所说的 Application 也不局限于用户应用代码，而是泛指调用 CanXcp 的任意上层软件。

1. CanXcp 的职责边界

XCP 栈可拆成协议语义和总线传输两层。协议层解析CONNECT、测量、标定、DAQ 等 XCP 语义；CanXcp 不重复实现这些命令，而是把接收到的 XCP L-SDU 交给协议层，再把协议层产生的响应或异步数据交给CanIf。

CAN 与 CAN FD 的差异直接体现在单个 XCP Packet 的长度上：经典 CAN PDU 最多承载 8 Byte；CAN FD Mode 2 最多承载 64 Byte。该上限还会影响全局MaxCto、MaxDto在各通道上的实际有效值。

2. 从命令接收到发送确认的完整链路

接收路径从CanIf回调开始。CAN Interface 收到 XCP L-PDU 后调用Xcp_CanIfRxIndication()，CanXcp 根据接收 PDU ID 和PduInfoType中的长度、数据指针，把 Packet 交给 XCP Protocol Layer。协议层处理命令后调用CanXcp_Send()提交响应，CanXcp 再通过CanIf_Send()发送。发送成功并不以CanIf_Send()返回为终点。CAN Interface 完成 L-PDU 发送后调用Xcp_CanIfTxConfirmation()，CanXcp 再通过Xcp_SendCallBack把确认传回协议层。SERV、EV和DAQ等异步 XCP Packet 也沿用这条发送与确认链路。

这条链路中，Rx PDU ID 用于识别收到的 CAN L-PDU，Tx PDU ID 用于关联成功发送的 L-PDU。所有相关 API 都是void，接口表没有定义返回错误码，因此链路推进依赖正确的 PDU 映射、回调配置和发送确认，而不是上层轮询返回值。

3. PDU 模式、发送队列与重试

CanXcp 初始化后的 PDU 模式固定为CANXCP_SET_OFFLINE。通常由 CAN State Manager 把它切换为在线；没有 CanSM，或状态管理器来自其他供应商时，应由集成代码调用：

CanXcp_SetPduMode(XcpNwH, CANXCP_SET_ONLINE);

如果没有完成这一步，CanXcp 不会发送 XCP 帧。进入离线模式并不等价于立即丢弃待发送数据：帧会保存在 Send Queue 中，直到重新在线或队列发生 overrun。

CanXcp_MainFunction()负责处理未能立即发送而进入队列的消息，并触发 CAN 上的 DAQ 消息。一般情况下由 Schedule Manager（SchM）周期调用；没有 SchM 或使用第三方 SchM 时，应用必须自行周期调度。

主函数周期有两种不同要求，不能只记住一个固定值。

当CanIf没有发送队列时，CanXcp 自身的主函数重试就成为关键补偿路径。周期不是越短越好，而是要在 XCP 响应延迟、DAQ 节拍和 ECU 任务负载之间选择；明确给出的参考值是常规场景5/10 ms，关闭 CanIf transmit queue 时1 ms。

4. PDU Mode 与组件启停不是同一个开关

CanXcp 提供两组容易混淆的运行期控制：CanXcp_SetPduMode()只控制 XCP 帧能否发送；XCP_ACTIVATE()和XCP_DEACTIVATE()控制 XCP Protocol Layer 与 Transport Layer 的整体功能。

XCP 默认处于组件已激活状态，但 PDU 模式在初始化后是离线状态。也就是说，“组件可执行”与“允许向 CAN 发送”是两个正交状态。量产项目若同时使用诊断激活和网络状态管理，必须分别维护这两个状态，不能用一个接口代替另一个。

4.1 Resume Mode 下为什么应使用 PDU Mode

Resume Mode 启用后，如果 CAN 总线尚未就绪，Resume Mode 触发的帧可能无法发送；随后 XCP 再次初始化，初始化过程又包含 Resume Mode 初始化，从而存在递归风险。对应的规避方法是使用 PDU Mode：总线未就绪时先保持CANXCP_SET_OFFLINE，让帧进入队列；总线可通信后再切换为CANXCP_SET_ONLINE。这一路径的关键不是“延后初始化”，而是把协议/会话初始化与总线可发送状态解耦。PDU Mode 能在总线未准备好时有效阻止发送，同时在队列未 overrun 的前提下保留帧。

5. MaxCto、MaxDto 配置与混合 CAN/CAN FD 通道

CanXcp 使用两个全局上限参数：

/MICROSAR/Xcp/XcpConfig/XcpTransportLayer/XcpOnCan/XcpOnCanMaxCto
/MICROSAR/Xcp/XcpConfig/XcpTransportLayer/XcpOnCan/XcpOnCanMaxDto

它们选择系统允许的最大 CTO/DTO 长度，但每个通道的实际值仍受该通道 PDU 大小限制。混合多通道系统可能同时存在 8 Byte Classical CAN PDU 和 64 Byte CAN FD PDU，此时全局MaxCto/MaxDto可以配置为64，经典 CAN 通道会自动限制为8。

因此，全局参数描述的是“最大可能值”，不是所有通道都强制使用同一帧长。协议层生成 Packet 时仍必须遵守当前逻辑通道对应的有效上限。

6. API、回调与协议层服务

6.1 协议层调用的 CanXcp 服务

CanXcp_Send()的Xcp_Channel取值受 Multi Client 配置影响：Multi Client 关闭时始终为0；开启时反映协议层逻辑 XCP 通道。len在经典 CAN 上为1..8，在 CAN FD 上为1..64。

6.2 CanIf 调用的传输层回调

这两个函数需要在生成工具中配置为CanIf的接收通知和发送确认回调。漏配TxConfirmation会让 CanXcp 无法把发送完成事件传递给协议层；Rx PDU ID 映射错误则会让接收到的 XCP L-SDU 无法进入正确逻辑通道。

6.3 其他层调用的服务与宏

6.4 CanXcp 调用的协议层接口

这些接口属于 XCP Protocol Layer，CanXcp 只负责在 CAN 传输事件发生时调用它们，不定义其内部协议行为。

7. 并发保护与独占区

CanXcp 使用CANXCP_EXCLUSIVE_AREA_0保证关键区的原子性。该独占区必须映射到允许嵌套调用的 interrupt lock/unlock 函数，因为Xcp_Event、Xcp_SendCallBack、Xcp_MainFunction和Xcp_Command可能相互打断。

CanXcp_Send、两个 CanIf 回调和主函数都不可重入，独占区配置不能只保护某一个入口。调度分析应同时纳入 CAN ISR、DAQ 事件上下文、后台处理和周期 Task，确认嵌套锁不会在回调链中被错误释放。

8. 交付文件、版本与 A2L 集成

8.1 实现和生成文件

未使用 GENy 配置 AUTOSAR CAN Interface 时，与项目适配直接相关的是CanXcp_Cfg.h、CanXcp_Lcfg.c和CanXcp_PBcfg.c这些生成文件；其余实现文件仍不应手工改写。

8.2 BCD 版本常量

CanXcp 提供三个可由应用随时读取的外部常量，用 BCD 形式表达主版本、次版本和发布版本：

kXcpOnCanAsrMainVersion = (CP_XCPONCANASR_VERSION >> 8);
kXcpOnCanAsrSubVersion = (CP_XCPONCANASR_VERSION & 0x00ff);
kXcpOnCanAsrReleaseVersion = CP_XCPONCANASR_RELEASE_VERSION;

例如版本1.00.00对应主版本0x01、次版本0x00、发布版本0x00。CanXcp_GetVersionInfo()返回的版本信息同样采用 BCD 编码，并同时提供 Vendor ID 和 AUTOSAR Module ID。

8.3 A2L 文件

GENy 会导出CanXCPAsr.a2l，其中包含XCP_ON_CAN IF_DATA段，可供 CANape 等 XCP Master 的主 A2L 模板引用：

/begin IF_DATA XCP
  /include "CanXCPAsr.a2l"
/end IF_DATA

这个文件解决的是 Master 侧 XCP on CAN 传输参数接入，不替代 ECU 内 CanIf PDU、CanXcp 通道和 PDU Mode 的配置。

9. 限制与明确不支持的能力

CanXcp 对 CAN Identifier、Slave 发现和 Multiple Identity 有三项明确限制。

这些限制应在 CANape 工程、A2L 组织和 ECU 通道规划阶段处理。特别是多通道方案，不能在集成后期再假设 Multiple Identity 或按 DAQ List 分配 CAN ID 可以由配置开关补上。

10. 集成与调试落点

排查“XCP 无响应”时，可以按固定方向缩小范围：先确认组件未被XCP_DEACTIVATE()，再确认 PDU 已在线，然后检查 Rx PDU 是否进入Xcp_CanIfRxIndication、协议层是否调用CanXcp_Send、帧是否进入 Send Queue、主函数是否周期执行，最后确认Xcp_CanIfTxConfirmation是否返回。这个顺序与实际数据路径一致，能区分协议问题、网络状态问题和调度问题。

11. 小结

CanXcp 的关键不在 XCP 命令解析，而在传输状态的闭环：CanIf接收回调把 Packet 送到协议层，CanXcp_Send把 CTO/DTO 送回 CAN，发送确认再通过Xcp_SendCallBack返回协议层。PDU 离线或 CanIf 暂时无法发送时，Send Queue 与CanXcp_MainFunction共同维持重试路径。集成风险主要集中在三处：初始化后没有切换到CANXCP_SET_ONLINE，把组件启停与 PDU Mode 混用，以及主函数周期和独占区没有覆盖实际并发场景。再加上 MaxCto/Dto 的通道限制和三项协议能力边界，CanXcp 的运行行为就能在 CAN、CAN FD、单通道和多通道项目中被明确约束。