赞的博客

Autosar进阶专栏索引

TJA1445作为TJA1145的升级版，具有功耗更低，价格更低的优势。本文介绍基于NXP官网的CDD包快速开发TJA1445软件1445使用也有一些坑的地方，后面有空再介绍。

诊断DTC开发中，会有故障快照和扩展数据的存储需求，但由于控制器的可用存储空间有限，所以无法存储所有DTC的信息，这时就需要限制存储的数量，本文介绍该参数在ETAS软件中的配置。此处主要是因为ETAS工具配置DTC个数需要在两个地方都配置，且第二个地方需要特殊设置才能配置，导致查了很久，本文主要是做个记录，方便后面查看。

CanSM模块主要是配置Busoff相关的参数，客户需求一般会指定对应的快慢恢复参数。本文介绍相关参数的定义及配置Busoff在客户前期测试过程中还是非常重视的，需求也非常明确，需要保证需求开发和测试对的上，否则出了问题，给客户解释就比较费劲了~

之前使用软件的Hash256和RSA2048算法，在HSE中也有对应的硬件实现，本文介绍这两种算法的配置及实现RSA算法作为非对称加密的典型算法，目前在软件刷写中应用十分广泛（私钥加签，公钥验签），如果硬件支持该算法，使用硬件算法也可以提高算法执行的速度。

Nvm中存储的数据，一般有两种存储方式，一个是立即存，一个是下电存，之前介绍过立即存的配置，本文介绍下电存的配置及实现

由于瑞萨官网的RH850P1XC的MCAL中未提供CAN模块，所以CAN需要另外第三方（例如ETAS）提供，本文介绍ETAS对应的实现方案。瑞萨芯片目前量产并未使用，只是暂时记录下CAN相关的开发。

在Autosar OS定义中，只有SC2和SC4支持Timing Protection(时间保护)，本文介绍ETAS RTA-OS中的时间保护的配置及实现。通过OS配置可以实现task和isr的时间监控，但是参数配置一定要设置合理，防止出现误触发的情况。

在E2E校验中，需要对Counter进行自增，但每个报文周期不一样，导致自增的周期不一样。且Counter应该在收到报文之后才进行自增。基于这些需求，本文介绍使用RTE Port中的参数来实现。规范中原文如下：使用Update flag可以检查数据是否更新，这里需要注意的是，必须是非队列的数据，且必须是显示（explicit）的接口enableUpdate存在于的配置中。

Autosar软件架构设计中，Connect通常来自于Composition之间Component之间Component与Composition之间（Delegation connectors），还有一种PassThrough目前暂未使用。通过Connect实现Port信号的传递，所以在Mapping时需要十分小心。为减少mapping的工作量以及降低出错概率，本文介绍两种AutoConnect的方法。

在项目开发过程中，在一次软件变更时，调整了task优先级之后导致应用层软件中的float数据经常性的变为NAN，导致应用层功能失效。本文记录下这个bug的分析及解决过程。该问题排查了好几天，最开始正向排查不出来，差点放弃了，ETAS OS也没有人支持，只能换一种思路，通过反向推，最终定位到问题，能完美解决，还是很欣慰的。遇到问题不可怕，Bug一直都会有，主要是在解决问题中的思路和方法，不断总结积累，总会越来越好的！

在HSE使用过程中，出现过一些必现和偶发的问题，本文总结一下问题原因和解决方案HSE使用过程中还遇到一些其他问题，下次再完善吧。

车载信息安全对于MCU的要求越来越高，debug口作为直接刷写调试程序的通道，对其进行保护是非常有必要的。本文介绍基于S32K324的Secure Debug的开发。Debug保护作为信息安全实施的重要一环，可以防止未受信任的软件通过debug口刷写。

ETAS工具导入DBC主要也是生成arxml用的，ETAS推荐使用Cobra导入，本文介绍导入过程及注意事项不管是导入DBC还是arxml，本质上都是为了生成对应的com协议栈，目的是为了减少重复的工作量，所以，前期定义好收发的矩阵很重要，一般导入一次之后，后面就可以按变更点手动更改了。

本文介绍基于ETAS工具对应的BIP包的下电过程，仅供参考。在最后调用SBC下电时，需要理清楚SBC的休眠流程，否则可能会出现休眠又唤醒情况。后面有空会介绍9471的休眠流程。

之前一直对核间通信的保护没有深入了解，本文学习IOC的实现过程，基于ETAS OS，对应S32K324芯片使用spinlock主要是为了多核通信中保证共享数据的一致性，而硬件的SEMA42中的gate机制，正好可以满足这一需求，但需要注意的是，gate针对的是domain，所以多核必须存在于不同的domain中（通过配置XRDC），否则，SEMA42相当于是不起作用的~

本文介绍基于ETAS工具的BIP包的启动过程，及在工具链中的相关配置。本文描述的启动不包含芯片端的启动，因为各芯片可能都不太一样，但到Main函数之后的流程，可以通用Autosar的流程启动之后主要由OS来管理任务的切换，对于ECU的下电，一般由网络管理模块来控制。这个可以在后面介绍。

之前介绍过OCC6的配置，在客户需求中还有OCC1-4的采样，由于需求理解偏差导致开发实现错误。本文记录正确的OCC1-4的配置及使用，基于ETAS软件。在开发过程中，对需求理解不清楚，不仅会导致测试工作难以开展，还会导致错误的需求实现，一个错误可能引发其他的好几个错误。所以，对于不清楚的需求，一定要与客户多沟通，以避免大量额外的工作量！

在软件刷写流程中，上位机(诊断仪)发送1002后，APP检查允许跳转boot后，在特定的ram（软复位不清除）写入指定置后通过触发软件复位来跳转到boot的。在APP跳转到Bootloader时，1002的回复有两种方式，一种是APP直接回复，然后跳转，另一种是APP回复NRC78，然后跳转，在Boot中回复。本文介绍这两种方式的实现。如果是在APP中回复，可以少发一个0x78，整体跳转时间可能会少一些。但是如果诊断在收到5002之后立马请求其他的服务，可能出现boot正在初始化而未正常接收到报文。

Autosar EcuM学习笔记-上电初始化执行函数及下电前执行函数，本文介绍在EcuM中的配置及使用。

上一篇文章介绍OS API的使用和编译器相关的指令，本文介绍该OS Port支持的硬件及相关注意事项本章主要和硬件中断，内核寄存器相关，这部分想弄的更清楚还需要看芯片手册和M7内核手册。其中提到OS使用single stack和必须要配置XRDC，是在之前调试过程中发现的问题（OS shutdown）和觉得有问题的地方os_vector_1和0使用相同的。目前看来使用single stack是合理的，XRDC需要配置，OS应该就不用改源码了。

在客户需求中，需要实现当ECU处于非网络休眠状态，诊断请求将触发ECU网络请求而维持网络通信，在诊断响应完成后释放上述网络请求。该功能在Autosar中有对应实现。本文介绍ETAS软件中的实现路径。在Dcm标准中，有如下需求定义：当ActiveDiagnostic处于，Dcm收到诊断请求激活时，会调用，使对应的网络的ComM进入状态.之后Ecu就会主动发送网络管理报文，用来维持网络通信诊断报文请求网络管理报文的功能，在Autosar标准协议栈中应该都是默认支持的。

项目开发过程中，有需求在31服务（Routine）收到请求时，等待应用层反馈执行完后再进行响应。所以pending一段时间，本文介绍该功能的实现。可能善于思考的朋友会问，如果条件不满足，一直返回DCM_E_PENDING不就相当于卡死了么。实际并非如此，在Autosar配置中，还有另外一个参数配置最多返回NRC78的次数（例如5），规范原文如下：当超过5次之后，Dcm将不再返回NRC78，而是返回NRC10，且Dcm_OpStatusType会返回DCM_CANCEL。之后，就不会再进入服务函数了。

客户需求中需要在指定电压范围内允许通信，而目前项目中通信主要由PNC控制，是由BswM模块配置的，本文通过新增一个SWC mode实现该功能。使用Bswm的Port进行逻辑判断，基本不需要手写太多代码，还是非常方便的。能配置的尽量不手写！

之前在调试过程中出现过进Os_Cbk_StackOverrunHook导致程序卡死的情况，当时是把task中的OsTaskStackAllocation改大之后就好了。当时不太清楚原理。所以有了本文。Autosar OS中支持对stack的监控，但是只在stack溢出时触发hook函数。OS中的二类中断和TASKstack的使用量可以通过API进行读取。本文介绍OS配置及代码实现。Os的task/isr stack监控需要提前设置一个最大stack使用，超过该之后会触发一个OverrunHook。

在诊断软件开发中，客户需求中需要对OCC6进行记录，但ETAS诊断协议栈的配置中没有OCC6的内部数据，本文介绍OCC6在ETAS工具链中的配置，及代码中实现。表示连续出现fail的操作周期，当操作周期内出现fail时加1，当操作周期内出现pass且未出现fail时清0（因为当前周期即使pass也无法判定后面不会出现fail，所以需要到当前操作周期结束才清0，实际表现就是下一个操作周期才看得出来被清掉了），或者达到Confirm时清0。

在诊断开发时，客户需求27服务解锁失败超过一定次数后需要回复NRC37，且计时一定时间后次数清0，且计时时间内复位的话延时计数器仍需保留。本文介绍该需求在Autosar下的实现。实际测试过程中，之前一直将写入NVM放入SetSecurityAttemptCounter函数中，手动测试时，触发延时，复位之后可以正常回NRC37，但在用客户脚本跑自动用例时却始终回复不了NRC37（也不是始终，偶尔一两次能回）。

嵌入式C语言执行的软件中，stack溢出会导致程序执行异常，严重可能导致直接进硬件异常中断软件执行过程中的stack监控是非常有必要的，ETAS的StackM模块实现了运行过程中的stack监控，对于多核系统，对每个核的stack进行监控。本文介绍StackM配置及使用。栈是用来存储函数调用时的局部变量函数参数以及返回地址等信息的数据结构。栈的生长方向一般是向下生长的，栈顶为高地址。当一个函数被调用时，它的局部变量和函数调用的参数都会被压入栈中，这会导致栈指针（通常称为栈顶指针或SP）向下移动，即向。

一般对CPU Load的测量，task及runnable的监控等有两种方案：1.需要使用带trace功能的调试器，且硬件也需要支持对应的trace接口2.使用软件Gliwa T1适配对应的软件程序，通过CAN通信进行监控以上两种方案所需的成本都不低，本文介绍基于ETAS RTM的配置实现CPU load测量/task时间测量/Isr时间测量，测量是基于定时器计数来的，可能不太准确，但是长时间的数据统计还是有一定参考意义的。使用RTM进行监控，可以对时间异常的任务进行优化，使软件运行更加高效稳定。

0x28服务主要用来控制非诊断报文的通讯，一般在刷写预编程过程中，用来禁止APP的通信报文，可以减少总线负载率，提高刷写成功率。本文介绍手动在ETAS工具中配置0x28服务。使用Dcm+BswM+Com配置即可实现0x28服务，不需要手写代码，还是非常方便的。

RTE中的Compostion内部的SWC之间的连接使用进行连接。这样的连接一般都是一个SWC的Pport对应另一个SWC的Rport。而Autosar软件中往往不只一个Composition(一般可以以核的数量作为Composition的数量)。此时我们考虑另外一种情况，Composition与Composition之前的通信，也是Pport对Rport，而SWC到Composition之间的port实际是同一种类型，此时，Delegation Connector的作用就体现出来了。

0x85服务用来控制DTC设置的开启和关闭。某OEM3.0架构强制支持0x85服务，本文介绍ETAS工具中的配置DTC控制服务一般在预编程过程，提前关闭DTC检测，以免在刷写过程中误报DTC。

之前介绍过AES-CMAC算法的配置，本文接着介绍随机数生成算法的配置及使用软件模拟的随机数，总会有重复的可能，使用HSE生成的随机数，可以避免这个问题。

通讯协议栈开发一般通过导入DBC实现，ETAS工具本身导入DBC也是生成arxml后执行cfggen,本文介绍直接导入客户提供的arxml文件，实现通讯协议栈的生成。通过Arxml导入相比于DBC来说，少了从DBC转为arxml的过程。而且arxml中能提供的信息也会更多。如果是DBC的话，很多信息（如PNC的映射，CANTP的配置等）都需要额外配置。不过还有连DBC都无法提供的，那就更麻烦了~

之前一篇文章介绍了导入DEXT之后在cfggen之前的更改，cfggen完成之后，就可以生成dcm,dem的配置了，但生成完配置后，如果直接生成BSW代码，会报错。本文介绍在cfggen完成后，生成BSW代码前的修改一般项目前期需要规划好诊断表的定义，尽可能少的进行cfggen的操作。包括通讯的协议栈也是如此。否则重复的工作量还是很大的。

诊断模块开发一般是先设计诊断数据库，OEM会释放对应的诊断数据库，如.odx文件或.cdd文件。如果OEM没有的话，只能先根据诊断表完成cdd文件。ETAS工具识别的是DEXT，也就是.arxml格式的诊断数据库文件，可以由.cdd文件通过导出为DEXT格式，导出方法不在本文描述范围。（如果是.odx文件，需要先转为.cdd，再转为DEXT）以上，cfggen之前的更改就介绍完了，下一篇文章介绍cfggen之后的更改。

ETAS工具的通讯协议栈，大部分是通过Cfggen生成的。在从客户那边拿到Arxml后，需要进行一些修改才能正常生成通讯栈的BSW配置，这种操作也会比较费时间。本文介绍在ETAS工具中手动配置PDU及Signal（以接收信号为例），保证能够正常生成代码及使用（本文不包括MCAL CAN的配置，默认mailbox已经配置好了）手动建立Signal，还是比较费劲的，尽量在项目前期阶段锁定网络中的接收与发送信号，避免重复的开发工作。

在车辆工作状态下，每个DTC检测可能都需要一个前提条件，否则如果任何条件下都可以进行DTC检测的话，可能会出现故障误报的情况。这个前提条件又称为(TRC).在DEM中，该需求可以由实现。本文介绍基于ETAS软件的相关配置及代码实现。使用EnableCondition可以同时配置多个DTC为同一个条件，也可按故障进行分类，不同类型的故障增加不同的条件，使用起来还是比较灵活的，不需要每个DTC都去单独做判断了。

Dem的配置基本由Cfgggen生成，但项目中有可能会有新增的需求，重新Cfggen比较费时间，本文介绍手动新建一个DTC，并配置其关联的参数，然后生成代码并使用该DTC使用Autosar Dem模块实现故障的触发，恢复，存储，数据记录，还是非常好用的。如果使用手写代码，工作量会更大，且bug可能也会更多。

本文介绍HSE固件的下载，及利用S32DS工程及PE工具安装。（本文只讨论对于full_men方式的HSE）HSE作为信息安全实现的载体，还是有很多需要学习的地方。