AUTOSAR软件架构---MCALWdg模块解析.docVIP

AUTOSAR软件架构---MCALWdg模块解析 1 模块简介 看门狗/Wdg模块是一个独立的定时器，可用于系统使用。它的作用是提供安全功能以确保软件按计划执行，并且CPU不会陷入无限循环或执行意外的代码。如果Wdg模块在一定时间内未被触发/刷新/喂狗，它将复位MCU。这是一个非常常用、非常重要的一个模块。 AUTOSAR MCAL Wdg模块主要提供以下服务/API： 初始化/Wdg_Init 设置模式/Wdg_SetMode 设置触发条件（设置超时时间/喂狗）/Wdg_SetTriggerCondition Wdg通常有两种，一种是芯片内部自带的片内看门狗；还有一种是在芯片外部通过SPI这种接口连接的片外看门狗。MCAL只负责第一种片内看门狗，片内看门狗的特点是Wdg模块是直接访问相关硬件寄存器。片外看门狗属于板级设备抽象层负责，通常需要使用MCAL提供的其他模块（比如SPI等）来访问/控制外扩看门狗芯片。这种不能直接访问硬件寄存器。 由于其特殊性，该模块的代码除了可以在ROM里面运行外，也可能会在RAM里面运行。比如在Bootloader刷写Flash时，Wdg模块可能作为二进制文件里面的一部分在RAM上运行。 本文内容基于目前最新版协议：R19-11 注意： 该模块不提供DeInit函数。如果的确需要关闭该模块，可通过调用Wdg_SetMode()函数，参数为OFF Mode来实现。 不提供DeInit函数的原因主要有两点： 1、因为很多硬件不支持关闭功能。 2、一些安全性要求高的系统不允许关闭看门狗。 片内和片外这两种体系结构差异导致的问题，在未来的版本中有计划得到解决。 实际情况，可能有些厂商在Wdg模块里面已经扩展了，也就是在里面也可以配置外挂看门狗。如果已经扩展了，通常片内和片外在使用上没有区别，API这些都是一样的。 2 模式简介 MCAL Wdg模块定义了三种模式，具体定义见下表： 模式定义 模式描述 Off Mode 该模式下，Wdg硬件关闭。有时候我们可能需要将整个ECU关闭，而不需要看门狗提供周期复位功能，这种情况下可使用该模式。但对于一些安全性要求很高的系统，通常关闭Wdg是不允许的，这种情况下，必须配置Wdg模块以防止切换到该模式。 Slow Mode 该模式用于监控那些具有较长超时时间的场景，比如系统启动阶段/初始化阶段。 Fast Mode 对于那些必须在很短超时时间内完成触发看门狗复位的场景则需使用此模式。比如ECU正常运行期间。又或者看门狗配置为窗口模式时（因为窗口模式必须在设置的最小和最大边界内去触发，通常这个窗口比较窄/时间短）。 3 实现原理 内部看门狗服务程序可以通过独立于其他外设的内部硬件计时器（Timer）中断来实现，也可以通过GPT驱动模块的回调函数来实现。如果不通过GPT实现，而通过中断（一类/二类中断）实现，则需要查看厂商提供的文档描述，通常它遵循一类/二类中断的使用条件/注意事项。但是不管哪种实现方式，标准里面并没有具体规定，由用户自行决定。 在之前的版本中，看门狗服务例程是由上层软件来调用的，这会有一个问题，就是很难保证针对窗口式看门狗这种严格的时间约束。新版协议对这部分做了优化。优化的基本思想是将用于维护看门狗硬件时序的服务例程与逻辑控制分开。触发看门狗的时基可以通过硬件来提供，这样可确保最小的时序抖动。而控制看门狗硬件的程序可直接在定时器中断函数里面实现以确保最小延迟。这两个条件（最小时序抖动、最小延迟）确保可以满足窗口式看门狗的时间窗口（也就是上一段提到的实现方法）。 为了保持上层模块（比如WdgM/Wdg管理器）的基本概念不变，Wdg驱动模块期望看门狗的控制逻辑（是否需要被触发/喂狗）由环境环境（WdgM）负责。 想想我们自己平时写代码直接去操作看门狗硬件寄存器，那么我们所能设置的触发时间/喂狗就完全由硬件决定了，通常这个时间不会太长，很多芯片在100ms这种级别。但是文章一开始说了Wdg模块提供3种模式，其中两种是Slow，Fast模式，如果这样的话，我们直接去操作硬件寄存器这种方法是不是就很难处理了，因为触发/喂狗周期都是固定的且比较短，但很多时候应用层可能并不需要那么严格的时间监控，可能秒级的周期即可（总之就是这个周期大于看门狗硬件寄存器的最大值了），这种情况是不是就需要应用层不断去喂狗，这对应用层的代码实现影响就很大了，他需要到处穿插喂狗函数。我想可能还有一个很重要的原因，现在大家对功能安全越来越重视，那么对这种频繁修改看门狗硬件寄存器的操作是不推荐的（本身他的操作性能就不高，通常需要一个序列才能进行修改）。 为了方便大家进一步理解，接下来我先说说我对实现方法的一种想法。其实实现原理也很简单。首先说一下Slow，Fast两种模式对时钟的要求，通常这两