Classic Autosar调试小结

一. 模块开发过程

1. 初版

基本是面向百度 熟悉概念+测试过程,然后根据SIP手册上手达芬奇等工具配置出初版后,生成代码,修改cmake,使用调试器慢慢调试.

1.1 Developer配置

SWC/CDD需要额外进行Developer的建模配置等,基本上都要生成对应的init和task函数,在此函数中进行需要的处理,记得将task放入Configurator里的Core n_...ms Task触发.

1.2 CDD配置

诊断相关模块需要配置CDD,建立相关的DID及匹配NvM.

1.3 XCP配置

CAN_XCP通过Xcp_CanIfRxIndication接收,ETH_XCP通过Xcp_SoAdRxIndication接收.

测试时A2L文件可以通过matlab的rtw.asap2SetAddress( 'A.a2l' , 'B.elf' )生成

1.4 Configurator配置

基本上分为模块的配置,Task配置,中断配置,SWC生成配置.

1.4.1 通信

从PDU开始配置起,CAN模块可以通过导入DBC生成然后改错,ETH需建立PDU,然后使用Soad(socket)模块建立Tx/Rx/Connection的信息,最后在上层配置直接使用PDU.

二. 调试小结

初次配置基本都会遇到进errHook/panicHook/DET等,根据报错的具体错误值排查对应的配置问题,根据笔者的少量经验,基本是某个勾没有勾/没有加入task/加入task的init不够/init顺序有问题等.

看门狗模块需要看芯片手册调时钟频率,喂狗需要控制到适当频率以免CPU负载过高/复位.

NvM模块是异步的,可通过判断Int_NvMultiBlockStatus使之变为同步,此外init时还需要由下至上init.

XCP模块需注意收到的报文进来的时候会有很多个,要确认是XCP报文再恢复断点调试.根据报文的最后一条断点打在相应command(Xcp_CmdStd_GetStatus)查找蛛丝马迹.

CFG的内联函数不好调试的情况可手动去除,提交代码时不要add即可.

利用CANape发送报文时需要check Page以及Host端口(可能会造成连接不稳定).

利用CANoe调试外接设备时需要注意channel,CAN/CANFD,波特率,采样点等,不然报文可能异常.

三. License小技巧

1. 实体License

USB over Network, 不用再拔来拔去实体License了.(甚至可以劳特巴赫远程调试)

2. 网络License

复制同样的虚拟机, 电脑一样的情况下,一个License也能多个同事使用了.

四. 编译技巧

咱们CP的工程起码两三个G吧, 全编一次极其痛苦, 编译及生成众多的产物也导致提交可能会多提东西.

1.将cmake封装进脚本(比如python),将编译环境搭建至docker,完成后新同事再也不用搭编译环境了.

2.将源代码映射进docker后, 使用如下语句,只拷贝有用的内容进行编译,起码可以加速十分钟

find . -type d \( -name RteAnalyzer -o -name tresos -o -name plugins \) -prune -false -o -name '*.c' -o -name '*.h' -o -name '*CMakeLists.txt'-o -name '*.lsl'

五.发版技巧

GitLab CI + Semantic-Release + JFrog + 编译脚本 + Docsify + 反Merge脚本 + JIRA + Confluence

懂的都懂(滑稽)