基于TC397的AUTOSAR BSW工程、MCAL工程编译与验证——确保Xcp功能、Can通...

基于TC397的autosar配置BSW工程，MCAL工程，编译通过的IDE工程。 工具是基于EB，davinci configurator，tasking（CBD19版本）或hightec（CBD24版本） 实际能在开发版上跑起来。 需要的联系，软件产品，不包含工具，不提供SIP（如果需要价格另议），不提供MCAL包，只是配置工程，读懂关键字 功能:支持Xcp功能(polling模式)，Can通信收发，OS6核跑起来

搞TC397+AUTOSAR这玩意儿，真不是个轻松活儿。特别是当需求里写着要OS六核全跑起来的时候，我对着EB Tresos Studio的配置界面愣是抽完了半包烟。今天咱就唠唠这个配置工程里几个要命的坑。

先看OS配置这块，六核调度玩的就是心跳。在DaVinci Configurator里核间通信配置不当直接死锁，我遇到过Core0和Core1互相等信号量，结果整个系统卡成PPT。后来发现得在OsScheduleTable里硬核分配时间片：

ScheduleTable = { .Duration = 10, .SchedulePoints = { { .Offset = 0, .Action = &AppTask_10ms }, { .Offset = 5, .Action = &ComTask_5ms } } };

每个核的ScheduleTable得像齿轮咬合那样精确，特别是当Xcp在Polling模式下抢资源的时候，时间窗重叠超过2ms就可能丢帧。有个邪门现象——把ScheduleTable的Duration值设为质数（比如7ms、11ms）反而能减少资源冲突，玄学得很。

Xcp配置最坑的是内存对齐。EB的Xcp模块配置界面有个隐藏选项，得手动改.arxml文件才能开启DMA优化。实测开启后Polling模式的传输效率能提升40%，但配置不当直接HardFault：

<XCP-GENERAL> <XCP-MEMORY-ALIGNMENT>32</XCP-MEMORY-ALIGNMENT> <XCP-DMA-ENABLED>true</XCP-DMA-ENABLED> <XCP-CALPAGE-BUFFER-SIZE>0x200</XCP-CALPAGE-BUFFER-SIZE> </XCP-GENERAL>

这个0x200的BufferSize是经验值，小了会丢数据，大了影响OS调度。最骚的是这个参数跟Tasking编译器优化等级强相关，开-O2时得再加16字节冗余。

Can通信配置要特别注意DMA通道分配。TC397的MultiCAN模块有六个节点，但只有三个DMA通道能用于AUTOSAR ComStack。实战中发现把NM报文和Xcp诊断报文分到不同DMA通道能避免总线仲裁冲突：

CanControllerCanCfg = { .CanControllerId = 0, .CanDmaChannel = 0, .CanTxProcessing = DELAYED, .CanRxProcessing = IMMEDIATE };

这里DELAYED模式必须配合硬件时间戳使用，否则总线负载率超过30%就开始丢帧。有个魔鬼细节——CanIf模块的HRH配置必须与CanDriver的HOH对象数量严格对应，差一个就等着看总线上幽灵报文乱飞吧。

工程编译更是个玄学现场。HighTec编译器对多核LDF文件极其敏感，有次手抖在Core4的链接脚本里多写了个.bss段，结果整个BSW的NVRAM管理崩了。建议编译参数里必须加-mtcr=all才能保证各核MMU配置同步：

CORE0_LDFLAGS += -Wl,--gc-sections -mtcr=all -mcore=tc3xx CORE1_LDFLAGS += -Wl,--gc-sections -mtcr=all -mcore=tc3xx

最后上板子实测，用Xcp协议栈暴力灌500帧/秒的数据包，看着六个核的CPU负载曲线在70%附近跳舞，那感觉比蹦迪还刺激。记住，所有核的看门狗超时时间必须比最长的ScheduleTable周期大1.5倍以上，否则跑着跑着突然给你来个全局复位，那酸爽...