Autosar代码阅读和调试方法

一、前言

众所周知Autosar工程代码量非常庞大,而且有非常多的宏定义,代码可读性非常不友好。但是目前国内外很多OEM和Tire1都是基于Autosar系统进行项目开发的。在开发过程中,出现一些BUG时必须去阅读和调试代码。这就要求开发人员具备很强代码阅读能力和调试能力。根据多年Autosar项目开发经验选择总结了代码阅读和调试的一些经验,如有不足之处,还望各位进行指出。

二、Autosar代码如何阅读

1、熟悉代码工程的结构

要提高Autosar代码阅读能力,首先得了解Autosar代码工程的结构。不然从几十万行代码中去找问题,会感觉到无从下手。下面大致的列出Autosar工程的结构,很多模块并没有一一列出。

其中MCAL、BSW和RTE大多是通过工具链如Davinci/ETAS,EB等配置出来的代码,当然还有Vector SIP包里的静态代码。ASW中算法模块一般可以用MBD建模通过Matlab/TargetLink工具生成的代码,当然这个里面也有很多根据软件需求手写的逻辑代码。复杂驱动里的代码也是根据芯片的Datasheet手写的驱动代码。

1.1 MCAL代码

MCAL部分的代码分成EB配置出来的代码和MCAL包里的静态代码,如下图所示:

1.2 BSW基础软件代码

基础软件部分的代码量非常大 ,主要包含两部分,一个是SIP包里的静态代码和工具链配置出来的代码,如下图所示为SIP包里按模块划分的静态代码:

另外一部分是用工具链生成的代码,如下图所示:

连接BSW和ASW的运行时环境RTE也是工具生成的,在GenData文件夹中。

1.3 ASW代码

ASW应用层代码主要包括MBD生成的算法和控制代码,以及手写代码。MBD建模生成的代码如下图所示:

其他有些手写代码也是在ASW中,例如诊断22/2E服务DID的读写逻辑代码的实现,如下图所示:

1.4 复杂驱动代码

复杂驱动代码包括一些驱动芯片和电源芯片的手写代码,这部分主要是手写代码,如下图所示:

以上就是Autosar代码工程的几大块。知道代码结构后,在项目开发过程中,若遇到了问题就知道从哪里去找到相应的代码打断点进行调试。

2、代码有问题从哪些地方查

当我们在开发过程中遇到了问题,从哪些代码入手查呢?首先要明白一点:MCAL静态代码是芯片厂商对外设模块写的一些固件代码,一般是没有问题;BSW静态代码是Vector随SIP包一起下发的,一般也是AUTOSAR标准的的代码,一般也是不会出问题的。所以就要查EB和Davinci配置的代码,复杂驱动和ASW部分的代码。当然在追查问题的时候或者弄清楚某个模块的原理,是需要结合所有代码一起看的。这样就把问题查找的范围缩小了。大家可以在实际项目中根据实际情况去做尝试。

注:有时候软件跑不起来了,该如何查呢?我在此讲一下我的思路:先查EcuM_AL_DriverInitZero/EcuM_AL_DriverInitOne/EcuM_AL_DriverInitTwo,BswM_Init,OsTask_Init_OsCore0这些初始化函数是否能正常运行?因为只有初始化运行完才会进入各个周期Task中。当这些初始化函数都跑不进去,那就要查一些资源和内存配置是否有问题,以及启动代码是否有问题。

三、代码调试技巧

在实际开发过程中,经常面临着程序跑飞的情况?我们一般的做法有:**打断点、看变量、对比正常代码和异常代码的变动。**实际上有些简单的问题可以用上述方法,但是有些问题并不能通过这几个方法查的出来。下面再介绍在开发阶段的三种调试方法查此类问题:

  • ErrorHook: 极少数情况使用。
  • Det: 在配置阶段,勾选相应模块Det Enable,但是报的信息太过笼统,有一定的作用,在开发阶段使用。
  • **PC指针:**可以精确定位到某一行,在开发阶段使用。

1. ErrorHook的使用

在OS_Callout_Stubs.c下面的函数,FUNC(void, OS_ERRORHOOK_CODE) ErrorHook(StatusType Error),这里面打断点。

如果程序真的进了ErrorHook,可以从CurrentError里面来捕获这个错误ID。怎么样破解这个ErrorID的具体含义?

最快捷的方法是,转到Os_Types.h中,在Os_StatusType这个enum的注释下面有对ErrorID的解释。

2. Det的使用

方法类同ErrorHook的使用。但要注意:要观察哪一块的错误,就要使能那一块的DET,比如,你的工程一进行ADC采集就跑飞,那么你必须要打开ADC模块的DET功能,和DET模块。这样你才能观测DET错误信息。

然后在Det.c模块的Det_ReportError进行错误信息的捕获。该函数中最有用的信息就是这4个参数:ModuleId、InstanceId、ApiId、ErrorId(也叫ErrorCode)。

关于ModuleID的定义,是AUTOSAR标准,所有SIP供应商都遵循的,在AUTOSAR标准《List of Basic Software Modules 》中可以查到。

在定位到Module以后,可以在每个Module的头文件代码下面或者TechnicalReferences下面(仅适用于Vector的工具)找到具体的ErrorCode/ErrorId的含义。这样就能大体定位出问题所在。

3. PC指针的使用

应对程序跑飞,这是目前博主认为最高效,也是博主最喜欢用的方法。这种方法几乎可以说是程式化的,其每一步都是固定且目的清晰的。

因为博主没用过其他软件调试工具,所以我还是给这个方法加一个适用条件,免得误导别人。

编译器: Tasking

调试软件: TRACE32

调试硬件: 劳特巴赫

芯片平台: 英飞凌AURIX系列

先说一下这个方法的原理,就是上下文切换机制。关于英飞凌CSA,网络上有不少讲解,可以参考一下这篇博文《TriCore处理器的上下文切换原理》。程序运行过程就是一个上下文的链表延伸的过程,这个链表的节点中记录着当前位置和历史位置。

第一步 :在TRACE32中,打开CPU/CSFR这个模块。

观察PC指针这个寄存器,是不是固定在某一个值不变,或者在某一个非常小的范围内跳动。

如上图,这个时候程序停在了0x80080098这个位置。

第二步 :打开Var/show Function视图。

这个视图里,有所有的函数列表,及他们各自对应地址区间,左边是函数名,右边一列是地址:

结合第一步中的0x8008009 8,找到该地址属于哪个函数。注意在"Find"窗口中最好不要直接搜索80080098 ,因为这是函数内的一个指令对应的地址,不一定恰好是函数边界地址。一个函数对应的是一个地址区间,所以可以按地址范围搜索,比如搜索800800 ,然后在搜索出来的结果中找到正确的0x80080098所在区间,即所属函数

第三步 :找到PC指针停在的哪个函数,然后在函数内部(比如第一条语句处)打断点。打断点之后重新运行程序,这个时候程序必然会停在断点处。

Note : 上图地址只作为示意,博主在家里写的博客,没有劳特巴赫,无法展示真实的调试过程。

第四步 :打开Var/show Stack视图。

你会发现在程序跑飞之前的函数调用关系尽收眼底。那么是谁引起的跑飞,就一目了然。注意:在STACK视图中越是靠上的函数越是时间上靠后的。即程序是从下面的函数调用上面的函数这样跳转的。

比如我们前期已近明确,一旦使能XCP功能,程序就跑飞, 那么在Stack视图中显示,XCP模块的最后一个函数是Xcp_CmdHlp_WriteMta(),那么我们就进入该函数,通过单步调试,定位出到底哪一行代码执行导致了程序进入Trap

相关推荐
老猿讲编程9 天前
AUTOSAR 规范中的设计模式:传感器执行器模式
设计模式·autosar
老猿讲编程13 天前
AUTOSAR CP 中 BswM 模块功能与使用介绍(2/2)
autosar·车载软件
经纬恒润17 天前
经纬恒润AUTOSAR成功适配芯钛科技Alioth TTA8车规级芯片
软件开发·autosar
车载诊断技术19 天前
电子电气架构---符合ASPICE 4.0 之软件开发流程(SWE)
网络·人工智能·架构·汽车·软件工程·autosar
车载诊断技术23 天前
电子电气架构---软件定义汽车,产业变革
网络·架构·汽车·软件工程·autosar·电子电器架构
汽车电子工具智慧库23 天前
LSL常见应用场景及示例培训笔记<一>
汽车·autosar·lsl
十六宿舍24 天前
【AUTOSAR 基础软件】PduR模块详解(通信路由)
单片机·汽车·autosar·嵌入式开发·车载·pdur·基础软件
车载诊断技术25 天前
智能汽车智能网联
网络·架构·汽车·软件工程·autosar
Trump. yang1 个月前
AutoSar CP 通信服务核心—Com模块详解
嵌入式硬件·can·autosar·通信原理
逸埃1 个月前
[AutoSar]BSW_Diagnostic_006 RoutineControl (0x31)的配置和实现
autosar·uds·dcm·rid