AUTOSAR_SWS_WatchdogDriver

Specification of Watchdog Driver


Introduction and functional overview


This document specifies the functionality, API and the configuration of the AUTOSAR Basic Software module watchdog driver (Wdg). 

This module provides services for initialization, changing the operation mode and setting the trigger condition (timeout). 

The functional requirements and the functional scope are the same for both internal and external watchdog drivers. Hence the API is semantically identical. 

An internal watchdog driver belongs to the Microcontroller Abstraction Layer (MCAL), whereas an external watchdog driver belongs to the Onboard Device Abstraction Layer. Therefore, an external watchdog driver needs other drivers (in MCAL) in order to access the microcontroller hardware.

Acronyms and Abbreviations


The glossary below includes acronyms and abbreviations relevant to the Watchdog Driver module that are not included in the [1, AUTOSAR glossary].


Definitions needed for understanding of the concepts


Related documentation


Input documents & related standards and norms 

[1] Glossary 
  • AUTOSAR_TR_Glossary 

[2] General Specification of Basic Software Modules 
  • AUTOSAR_SWS_BSWGeneral 

[3] Layered Software Architecture 
  • AUTOSAR_EXP_LayeredSoftwareArchitecture 

[4] Requirements on Watchdog Driver 
  • AUTOSAR_SRS_WatchdogDriver 

[5] General Requirements on Basic Software Modules 
  • AUTOSAR_SRS_BSWGeneral 

[6] General Requirements on SPAL 
  • AUTOSAR_SRS_SPALGeneral 

Related specification 

AUTOSAR provides a General Specification on Basic Software modules [2, SWS BSW General], which is also valid for Watchdog Driver. 

Thus, the specification SWS BSW General shall be considered as additional and required specification for Watchdog Driver.

Dependencies to other modules 

A Wdg module for an internal (on-chip) watchdog accesses the microcontroller hardware directly and is located in the Microcontroller Abstraction layer. 

A Wdg module for an external watchdog uses other modules (e.g. SPI) to access the external watchdog device. Such a Wdg module is located in the Onboard Device Abstraction Layer (see [3]).

[SWS_Wdg_00055]
[ ]
  • The Wdg module for an external watchdog driver shall have source code that is independent of the microcontroller platform.

File structure

Code file structure

[SWS_Wdg_00079]
[SRS_BSW_00346]
[SRS_BSW_00314]
[SRS_SPAL_12263]
  • The code file structure shall not be defined within this specification completely. At this point it shall be pointed out that the code-file structure shall include the following files (as far as required; for name expansion see SWS_ Wdg_00169):
    • Wdg_Lcfg.c - for link time configurable parameters
    • Wdg_PBcfg.c - for post build time configurable parameters 
  • In case an internal watchdog servicing is implemented as interrupt routine, code-file structure shall include Wdg_Irq.c for holding the interrupt frames. 
  • These files shall contain all link time and post-build time configurable parameters.

Note: 

These names are required by SRS_BSW_00314 and SRS_BSW_00346.

[SWS_Wdg_00169]
[SRS_BSW_00347]
  • If more than one watchdog driver instance exists on an ECU (namely an external and an internal one) the implementer shall provide unique code file names by expanding the names according to SRS_BSW_00347.

Header file structure

[SWS_Wdg_00170]
[SRS_BSW_00347]
  • If more than one watchdog driver instance exists on an ECU (namely an external and an internal one) the implementer shall provide unique header file names by expanding the names according to SRS_BSW_00347.

Note:

In case of multiple watchdog driver instances, the Event Id symbols for production errors defined in this specification (see SWS_Wdg_00010 and ECUC_Wdg_00148) might be expanded in the configuration of the DEM in order to make them unique.

Version check 

For details refer to the chapter 5.1.8 "Version Check" in SWS_BSWGeneral.

System clock 

If the hardware of the internal watchdog depends on the system clock, changes to the system clock (e.g. PLL on PLL off) may also affect the clock settings of the watchdog hardware.

Onboard communication handlers 

A Wdg module for an external watchdog device depends on the API and capabilities of the used onboard communication handlers or drivers (e.g. SPI handler).

Requirements Tracing 

The following tables reference the requirements specified in [4] and links to the fulfillment of these. Please note that if column "Satisfied by" is empty for a specific requirement this means that this requirement is not fulfilled by this document.


Functional specification 


General design rules

[SWS_Wdg_00086]
[SRS_BSW_00167]
[SRS_BSW_00004]
  • The Wdg module shall statically check the configuration parameters (at the latest during compile time) for correctness.

[SWS_Wdg_00031]
[SRS_BSW_00336]
[SRS_SPAL_12163]
  • The Wdg module shall not implement an interface for deinitialization/shutdown. If the watchdog supports a de-initialization/shutdown and the environment allows the usage of this feature, the de-initialization/shutdown shall be achieved by calling the Wdg_SetMode routine with OFF mode parameter.

Rationale: 

Some watchdogs do not support the de-initialization/shutdown functionality and in some environments this feature must not be used (e.g. in safety critical systems).

[SWS_Wdg_00040]
[SRS_BSW_00426]
[SRS_BSW_00429]
  • If interrupts have to be disabled in order to ensure data consistency or correct functionality of this module (e.g. while switching the watchdog mode or during the watchdog trigger routine), this shall be done by using the corresponding BSW Scheduler functionality if possible (this means definition of an exclusive area). The internal watchdog driver (because it belongs to MCAL) may also directly disable interrupts - see SRS_BSW_00429.

[SWS_Wdg_00168]
[ ]
  • Depending on a static configuration (see ECUC_Wdg_00147), the code of the Wdg module is executed either from ROM or from RAM.

Motivation: 

For certain use cases, e.g. for flash programming in bootloader mode, the watchdog module has to be part of an executable which runs in RAM. 

Hint: 

This is more a requirement for the build environment than for the watchdog module itself. However, since it might also influence the implementation of the code, it is stated here and a corresponding configuration parameter is given.

External watchdog driver

[SWS_Wdg_00076]
[SRS_SPAL_12092]
  • To access the external watchdog hardware, the corresponding Wdg module instance shall use the functionality and API of the corresponding handler or driver, e.g. the SPI handler or DIO driver.

Note: 

The routine servicing an external watchdog may be implemented by usage of an own internal hardware timer to be independent from other peripherals or by using a GPT driver callback.

Hint: 

An external watchdog driver is part of the Onboard Device Abstraction Layer (see [3]), which excludes direct hardware access. 

This architectural discrepancy will be resolved in an upcoming release.

[SWS_Wdg_00077]
[SRS_Wdg_12165]
  • A Wdg module for an external watchdog shall satisfy the same functional requirements and offer the same functional scope as a Wdg module for an internal watchdog. Hence their respective APIs are semantically identical.

[SWS_Wdg_00078]
[SRS_Wdg_12166]
  • The Wdg module shall add all parameters required for accessing the external watchdog hardware, e.g. the used SPI channel or DIO port, to the module's published parameters and to the module's configuration parameters.

Internal watchdog driver

[SWS_Wdg_00161]
[ ]
  • To access the internal watchdog hardware, the corresponding Wdg module instance shall access the hardware for watchdog servicing directly.

Hint: 

An internal watchdog driver is part of the Microcontroller Abstraction Layer (see [3]), which allows direct hardware access. 

Note: 

The routine servicing an internal watchdog may be implemented by usage of an internal hardware timer to be independent from other peripherals or by using a GPT driver callback." 

If the watchdog servicing routine is implemented as an interrupt routine (i.e. as a cat1 or cat2 interrupt routine and not via the GPT), it shall be described in the Basic Software Module Description and the implementation shall follow the requirements for interrupt handling as given by [5] and [6] (SRS_BSW_00427, SRS_BSW_00325, SRS_ BSW_00439, SRS_BSW_00314, SRS_BSW_00429, SRS_SPAL_12129).

Triggering concept to support windowed watchdogs

In former versions of this specification, the watchdog servicing routine was called from an upper layer of the software which made it difficult to guarantee timing constraints namely for windowed watchdog conditions. This concept has been changed leading to the requirements explained in this chapter. 

The basic idea of this concept is to decouple the timing for servicing the watchdog hardware from the logical control.

The time base for triggering the watchdog may be provided by means of hardware. This ensures minimum timing jitter. Servicing of the watchdog hardware directly from a timer ISR ensures minimum latencies." 

These two conditions - minimum jitter and latencies - ensure that the time window of a windowed watchdog can be met. 

The Wdg Driver expects, that the logical control of the watchdog (whether the watchdog shall be triggered or not) shall be the responsibility of the environment, e.g. the Wdg Manager, so that the basic concepts of the Wdg Manager (alive supervision) shall remain unchanged.

[SWS_Wdg_00144]
[SRS_Wdg_12019]
  • The Wdg Manager (or other entities) shall control the watchdog driver via a so called trigger condition: as long as the trigger condition is valid the Wdg Driver services the watchdog hardware, if the trigger condition becomes invalid the Wdg Driver stops triggering and the watchdog expires. 
  • The semantics of the trigger condition can be interpreted as a "permission to service the watchdog for the next n milliseconds". Within this time frame the trigger condition has to be updated by the controlling entity else the watchdog will expire. 
  • Handover of the watchdog control logic is simply done by shared usage of the trigger condition (e.g. during startup / shutdown).

[SWS_Wdg_00134]
[SRS_Wdg_12019]
  • If the trigger counter is greater than zero, the watchdog servicing routine shall decrement the trigger counter and trigger the hardware watchdog.

[SWS_Wdg_00135]
[SRS_Wdg_12019]
  • If the trigger counter has reached zero, the watchdog servicing routine shall do nothing (i.e. the watchdog is not triggered and will therefore expire).

[SWS_Wdg_00093]
[SRS_Wdg_12019]
  • If the watchdog hardware requires an activation code which can be configured or changed, the Wdg Driver shall handle the activation code internally. In this case, the Wdg Driver shall pass the correct activation code to the watchdog hardware and the watchdog hardware in turn shall update the Wdg module's internal variable where the next expected access code is stored.

[SWS_Wdg_00094]
[SRS_Wdg_12019]
  • If the watchdog hardware requires an activation code which can be configured or changed, the trigger cycle of the Wdg Driver shall be defined with a value so that updating the activation code by the watchdog hardware can be guaranteed (see Figure 2).

[SWS_Wdg_00095]
[SRS_Wdg_12019]
  • If the watchdog hardware requires an activation code which can be configured or changed and the initial activation code can be configured, the activation code shall be provided in the Wdg Driver's configuration set. If the activation code is fixed for a particular hardware the above requirement can be ignored.

[SWS_Wdg_00035]
[SRS_BSW_00337]
  • When development error detection is enabled for the Wdg Driver module: the watchdog servicing routine shall check whether the Wdg module's state is WDG_IDLE (meaning the watchdog driver and hardware are initialized and the watchdog is currently not being triggered or switched). If this is not the case, the function shall not trigger the watchdog hardware but raise the development error WDG_E_DRIVER_ STATE.

[SWS_Wdg_00052]
[SRS_BSW_00337]
  • When development error detection is enabled for the Wdg Driver module: the watchdog servicing routine shall set the Wdg module's state to WDG_ BUSY during its execution (indicating, that the module is busy) and shall reset the module's state to WDG_IDLE (indicating, that the module is initialized and not busy) as last operation before it returns.

Note: 

This specification prescribes the symbols WDG_IDLE and WDG_BUSY only, if they are externally visible, e.g. for debugging (see SRS_BSW_00335). Choosing the data type for the status variable is up to the implementation. 

Hint for the integration: 

The Wdg module's environment shall make sure that the Wdg Driver module has been initialized before watchdog servicing routine is called.

Error Classification 

Section 7.x "Error Handling" of the document "General Specification of Basic Software Modules" describes the error handling of the Basic Software in detail. Above all, it constitutes a classification scheme consisting of five error types which may occur in BSW modules. 

Based on this foundation, the following section specifies particular errors arranged in the respective subsections below.

Development Errors

[SWS_Wdg_00010]
[SRS_BSW_00337]
[SRS_BSW_00350]
[SRS_BSW_00385]
[SRS_BSW_00327]
[SRS_BSW_00331]

Extended Production Errors

[SWS_Wdg_00178]
[ ]

[SWS_Wdg_00180]
[SRS_BSW_00327]
[SRS_BSW_00331]
[SRS_BSW_00466]
[SRS_BSW_00385]
  • The extended production error WDG_E_MODE_FAILED shall be reported with FAILED when setting of the watchdog mode failed.

[SWS_Wdg_00181]
[SRS_BSW_00327]
[SRS_BSW_00331]
[SRS_BSW_00466]
[SRS_BSW_00385]
  • The extended production error WDG_E_MODE_FAILED shall be reported with PASSED when setting of the watchdog mode not failed.

[SWS_Wdg_00179]
[ ]

[SWS_Wdg_00182]
[SRS_BSW_00327]
[SRS_BSW_00331]
[SRS_BSW_00466]
[SRS_BSW_00385]
  • The extended production error WDG_E_DISABLE_REJECTED shall be reported with FAILED when disabling of the watchdog mode failed.

[SWS_Wdg_00183]
[SRS_BSW_00327]
[SRS_BSW_00331]
[SRS_BSW_00466]
[SRS_BSW_00385]
  • The extended production error WDG_E_DISABLE_REJECTED shall be reported with PASSED when disabling of the watchdog mode not failed.

API specification


[SWS_Wdg_00172]
[SRS_BSW_00347]
  • If more than one watchdog driver instance exits on an ECU (namely an external and an internal one) the API names and instance specific type names specified in this chapter shall be made unique by expansion according to SRS_ BSW_00347.

Imported types 

In this chapter all types included from the following modules are listed:

[SWS_Wdg_00105]
[ ]

Type definitions 

Wdg_ConfigType

[SWS_Wdg_00171]
[SRS_BSW_00414]

Function definitions 

Wdg_Init

[SWS_Wdg_00106]
[SRS_BSW_00358]
[SRS_BSW_00414]

[SWS_Wdg_00001]
[SRS_BSW_00400]
[SRS_BSW_00101]
[SRS_Wdg_12105]
  • The Wdg_Init function shall initialize the Wdg module and the watchdog hardware, i.e. it shall set the default watchdog mode and timeout period as provided in the configuration set.

Note: 

Via post-build configuration, the user can choose the configuration set to be used with the Wdg_Init function from a limited number of statically configured sets (see also SRS_BSW_00314).

[SWS_Wdg_00100]
[SRS_SPAL_12057]
[SRS_SPAL_12125]
[SRS_SPAL_12461]
[SRS_Wdg_12105]
  • The Wdg_Init function shall initialize all global variables of the Wdg module and set the default watchdog mode and initial timeout period

[SWS_Wdg_00101]
[SRS_SPAL_12057]
[SRS_SPAL_12125]
[SRS_SPAL_12461]
[SRS_Wdg_12105]
  • The Wdg_Init function shall initialize those controller registers that are needed for controlling the watchdog hardware and that do not influence/depend on other (hardware) modules. 
  • Registers that can influence or depend on other modules are initialized by a common system module.

[SWS_Wdg_00025]
[SRS_BSW_00323]
[SRS_SPAL_12163]
[SRS_Wdg_12106]
  • If disabling the watchdog is not allowed (because pre-compile configuration parameter WdgDisableAllowed == OFF) and if the default mode given in the provided configuration set disables the watchdog, the Wdg_Init function shall not execute the initialization but raise the extended production error WDG_E_DISABLE_ REJECTED.

[SWS_Wdg_00173]
[ ]
  • If switching the Wdg module and the watchdog hardware into the default mode is not possible, e.g. because of inconsistent mode settings or because some timing constraints have not been met, the Wdg_Init function shall raise the extended production error WDG_E_MODE_FAILED.

[SWS_Wdg_00090]
[SRS_BSW_00323]
[SRS_SPAL_12448]
  • When development error detection is enabled for the Wdg module: The Wdg_Init function shall check that the (hardware specific) contents of the given configuration set is within the allowed boundaries. If this error is detected, the function Wdg_Init shall not execute the initialization but raise the extended error WDG_ E_PARAM_CONFIG.

[SWS_Wdg_00019]
[SRS_BSW_00406]
[SRS_BSW_00335]
  • When development error detection is enabled for the Wdg module: The Wdg_Init function shall set the Wdg module's internal state from WDG_ UNINIT (the default state indicating a non-initialized module) to WDG_IDLE if the initialization was successful.

Note: 

This specification prescribes the symbols WDG_IDLE and WDG_UNINIT only, if they are externally visible, e.g. for debugging (see SRS_BSW_00335). Choosing the data type for the status variable is up to the implementation.

Wdg_SetMode

[SWS_Wdg_00107]
[ ]

[SWS_Wdg_00160]
[SRS_Wdg_12015]
[SRS_Wdg_12018]
  • The function Wdg_SetMode shall switch the watchdog driver from the current watchdog mode into the mode given by the argument Mode. This means: By choosing one of a limited number of statically configured settings (e.g. toggle or window watchdog, different timeout periods) the Wdg module and the watchdog hardware are switched to one of the following three different modes:  
    • WDGIF_OFF_MODE  
    • WDGIF_SLOW_MODE 
    • WDGIF_FAST_MODE 

[SWS_Wdg_00051]
[SRS_Wdg_12015]
  • The configuration set provided to the Wdg module's initialization routine shall contain the hardware/driver specific parameters to be used in the different watchdog modes.

[SWS_Wdg_00145]
[ ]
  • The Wdg_SetMode function shall reset the watchdog timeout counter based on the new watchdog mode i.e. the timeout frame remaining shall be recalculated based on a changed trigger period.

[SWS_Wdg_00103]
[ ]
  • The Wdg_SetMode function shall return E_OK if the mode switch has been executed completely and successfully, i.e. all parameters of the Wdg module and the watchdog hardware have been set to the new values

[SWS_Wdg_00016]
[SRS_SPAL_12064]
  • If switching the Wdg module and the watchdog hardware into the requested mode is not possible, e.g. because of inconsistent mode settings or because some timing constraints have not been met, the Wdg_SetMode function shall return the value E_NOT_OK and raise the extended production error WDG_E_MODE_ FAILED.

[SWS_Wdg_00026]
[SRS_BSW_00323]
[SRS_SPAL_12163]
[SRS_Wdg_12106]
  • If disabling the watchdog is not allowed (e.g. in safety relevant systems, seeECUC_Wdg_00115) the Wdg_SetMode function shall check whether the settings for the requested mode would disable the watchdog. In this case, the function shall not execute the mode switch but raise the extended production error WDG_ E_DISABLE_REJECTED and return with the value E_NOT_OK.

[SWS_Wdg_00091]
[SRS_BSW_00323]
[SRS_SPAL_12448]
  • When development error detection is enabled for the Wdg module: The Wdg_SetMode function shall check that the parameter Mode is within the allowed range. If this is not the case, the function shall not execute the mode switch but raise development error WDG_E_PARAM_MODE.

[SWS_Wdg_00092]
[SRS_BSW_00323]
[SRS_SPAL_12448]
  • When development error detection is enabled for the Wdg module: The Wdg_SetMode function shall check that the (hardware specific) settings for the requested mode are within the allowed boundaries. If this is not the case, the function shall not execute the mode switch but raise the development error WDG_E_ PARAM_MODE.

[SWS_Wdg_00017]
[SRS_BSW_00335]
[SRS_SPAL_12064]
[SRS_SPAL_12448]
  • When development error detection is enabled for the Wdg module: The Wdg_SetMode function shall check that the Wdg module's state is WDG_IDLE (meaning the Wdg module and the watchdog hardware are initialized and the watchdog is currently not being triggered or switched). If this is not the case, the function shall not execute the mode switch but raise the development error WDG_E_DRIVER_ STATE.

[SWS_Wdg_00018]
[SRS_BSW_00335]
  • When development error detection is enabled for the Wdg module: The function Wdg_SetMode shall set the Wdg module's state to WDG_BUSY during its execution (indicating, that the module is busy) and shall reset the Wdg module's state to WDG_IDLE as last operation before it returns to the caller.

Note: 

This specification prescribes the symbols WDG_IDLE and WDG_BUSY only, if they are externally visible, e.g. for debugging (see SRS_BSW_00335). Choosing the data type for the status variable is up to the implementation.

Wdg_SetTriggerCondition

[SWS_Wdg_00155]
[SRS_BSW_00343]

[SWS_Wdg_00136]
[ ]
  • The function Wdg_SetTriggerCondition shall reset the watchdog timeout counter according to the timeout value passed.

[SWS_Wdg_00138]
[ ]
  • The timeout value passed shall be interpreted as 'milliseconds'. The conversion from milliseconds to the corresponding counter value shall be done internally by the Wdg module.

[SWS_Wdg_00139]
[ ]
  • The current watchdog mode shall be taken into account when calculating the counter value from the timeout parameter.

[SWS_Wdg_00140]
[ ]
  • This function shall also allow to set "0" as the time frame for triggering which will result in an (almost) immediate stop of the watchdog triggering and an (almost) instantaneous watchdog reset of the ECU. In case the counter value stored inside watchdog has the value "0", the service Wdg_SetTriggerCondition shall do nothing, which means it shall ignore the counter passed by the parameter to Wdg_ SetTriggerCondition.

[SWS_Wdg_00146]
[ ]
  • When development error detection is enabled for the module: The function Wdg_SetTriggerCondition shall check that the timeout parameter given is less or equal to the maximum timeout value (WdgMaxTimeout). If this is not the case the function shall not reload the timeout counter but raise the development error WDG_ E_PARAM_TIMEOUT and return to the caller.

Wdg_GetVersionInfo

[SWS_Wdg_00109]
[ ]

[SWS_Wdg_00174]
[ ]
  • If development error detection is enabled for the Wdg Driver module, the function Wdg_GetVersionInfo shall raise WDG_E_PARAM_POINTER, if the argument is a NULL pointer and return without any action.

Expected interfaces 

This chapter lists all functions that the Wdg module requires from other modules.

Mandatory interfaces 

This module does not require any mandatory interfaces.

Optional interfaces 

This chapter lists all interfaces which are required to fulfill an optional functionality of the module.

[SWS_Wdg_00111]
[ ]

In addition to the functions listed above, further functions might be used to access the external watchdog over Dio or Spi.

Sequence diagrams


Watchdog initialization, setting trigger condition and mode. 

The diagram shows the sequence to initialize the Wdg module, to set the trigger condition and to change the watchdog mode. Note that this is only an example. Especially, another "client" module than the Watchdog Manager (WdgM) could set the trigger condition.


Data exchange between watchdog driver and hardware 

The diagram shows the sequence to trigger the watchdog hardware when the WDG servicing routine is implemented as an interrupt routine. Note that this is only an example and the triggering routine is implementation specific. For an external watchdog, the watchdog hardware cannot be accessed directly, but only via drivers of the MCAL layer, like SPI or DIO.


Configuration specification 


In general, this chapter defines configuration parameters and their clustering into containers. In order to support the specification Chapter 10.1 describes fundamentals. It also specifies a template (table) you shall use for the parameter specification. We intend to leave Chapter 10.1 in the specification to guarantee comprehension. 

Chapter 10.2 specifies the structure (containers) and the parameters of the module Wdg. 

Chapter 10.3 specifies published information of the module Wdg.

How to read this chapter 

For details refer to the chapter 10.1 "Introduction to configuration specification" in SWS_BSWGeneral. 

Containers and configuration parameters 

The following chapters summarize all configuration parameters. The detailed meanings of the parameters describe Chapter 7 and Chapter 8.

Wdg


















The three modes are provided as containers for the reason that they might be referred by other modules and hence no parameters are needed. However those containers might be extended by the vendor (resp. hardware) specific configuration parameters, but these could not be standardized.

WdgSettingsFast






Published Information 

For details refer to the chapter 10.3 "Published Information" in SWS_BSWGeneral. 

WdgPublishedInformation



WdgTriggerMode is only published for information purposes; this parameter is not used to configure the Watchdog Driver or the modules using the Watchdog Driver.

评论

发表评论

此博客中的热门博文

ISO 14229-1-2020

图片
ISO 14229-1-2020 服务流程 service request primitive（服务请求） -  确认 模式/ 未确认 模式 service request-confirmation primitive（服务请求发送成功） -  确认 模式/ 未确认 模式 service indication primitive（服务请求接收成功） -  确认 模式/ 未确认 模式 service response primitive（服务应答） -  确认 模式 service response-confirmation primitive（服务应答发送成功） -  确认 模式 service confirmation primitive（服务应答接收成功） -  确认 模式 A_Mtype（诊断服务应用层数据格式） diagnostics                                -      A_SA ， A_TA 寻址 remote diagnostics                 -    A_SA ， A_TA 及 额外 信息寻址 secure diagnostics                  -    A_SA ， A_TA 寻址 安全 服务器 secure remote diagnostics    -     A_SA ， A_TA 及 额外 信息寻址 安全 服务器 接口描述 service_name.type (       parameter ...
Read more »

AUTOSAR_SWS_CANDriver

图片
AUTOSAR_SWS_ CAN Driver 简介和功能概述 该规范指定了 AUTOSAR 基础软件模块 CAN 驱动程序（在本文档中称为“Can 模块”）的功能、 API 和配置。 CAN 模块属于最低层，执行硬件访问并向上层提供独立于 硬件 的 API 。 唯一可以访问  CAN  模块的上层是 Can If 模块（另请参阅  SRS _ SPAL _12092）。 CAN  模块提供启动传输的服务，并调用  Can If  模块的回调函数来通知 事件 ，独立于 硬件 。 此外，它还提供控制属于同一 CAN 硬件 单元的 CAN 控制器 的行为和状态的 服务 。 只要属于同一个 CAN 硬件 单元， 多 个 CAN 控制器 就可以由单个 CAN 模块控制。 有关 CAN 控制器 和 CAN 硬件 单元的详细描述，请参见首字母缩略词和缩写章节以及[5]中的图表。 首字母缩略词和缩写 优先级反转 如果只使用单个传输 缓冲区 ，则可能会发生内部 优先级 反转。 由于 优先级 较低，存储在 缓冲区 中的 消息 会等待，直到“总线上的流量平静下来”。 在等待期间，此 消息 可能会阻止同一微控制器生成通过总线传输的更高 优先级 的 消息 。 外部 优先级 反转问题可能出现在某些 CAN 实现中。 假设 CAN 节点希望传输一组具有高 优先级 的连续 消息 ，这些 消息 存储在不同的 消息 缓冲区 中。如果 CAN 网络上这些 消息 之间的 帧间空间 大于 CAN 标准定义的 最小 空间，则第 二 个节点能够开始传输较低 优先级 的 消息 。 最小 帧间空间 由 间歇字段 确定，该字段由 3 个隐性 bit 组成。 之前由于另一条 消息 的传输而处于待处理阶段的 消息 ，将在总线空闲期间开始被传输，最快可紧随 间歇字段 之后，从 间歇字 段 之后的第 一 个 bit 开始。 例外情况是，具有待传输的 消息 的节点会将 间歇字段 的第三个 bit 解释为显性 bit ，并以此 bit 作为帧的起始位，开始传输帧的第一个标识符位，而无需先传输 SOF 位。 CAN 模块的内部处理时间必须足够 短 ，以发送具有最小 帧间空间 的连续 消息 ，以避免在上述所有情况下出现外部 优先...
Read more »

Linux Driver Char Device 笔记

图片
1.打開設備 设备节点           本质上和文件节点相同，为操作驱动的基本单位 文件节点          只用来做文件操作 打开设备文件的步骤：           chrdev_open完成的主要工作是：首先根据设备号找到添加在内核中代表字符设备的cdev （cdev是放在cdev_map散列表中的，驱动加载时会构造相应的cdev并添加到这个散列表中，并且在构造这个cdev时还实现了一个操作方法集合，由cdev的ops成员指向它），找到对应的cdev对象后，用cdev关联的操作方法集合替代之前构造的file结构中的操作方法集合，然后调用cdev所关联的操作方法集合中的打开函数，完成设备真正的打开操作，这也标志着do_filp_open函数基本结束。 使用的时候是先用inode找到对应的cdev，然后cdev对象包含对应的操作集file_operations。 并且在以下情况时，驱动程序会根据入口函数 static int cdev_open ( struct inode* inodp, struct file* filp ) 将 和具体设备 相关的 驱动数据 与 file 结构建立关联： 打开代表设备的inode 初始化要作为file来操作的设备 这样 file 结构就包含对驱动操作的 操作集 及 与具体设备挂钩的 驱动私有数据 了，这样就能对 file 进行操作进而 控制相关设备 了。 打开一个 cdev 的步骤： 打开对应 inode 通过 indoe 找到对应 cdev 将与 cdev 相关的 设备数据 及 驱动操作集 与 要作为文件操作的代表驱动的 file 结构 相挂钩 2.IOCTL ioctl 命令编码规则 31 30 ----------(2 Byte) 00 00     -     命令不带参数 00 01     -     向驱动传递参数，写入 01 00     -     从 驱动获取数据，读出 01 01   ...
Read more »

AUTOSAR_SWS_PWMDriver

图片
AUTOSAR_SWS_ PWM Driver 简介和功能概述 该规范指定了 AUTOSAR 基础软件模块 PWM 驱动程序的功能、 API 和配置。 每个  PWM  通道都链接到微控制器的硬件 PWM 。 PWM  信号的类型（例如居中对齐、左对齐等）未在本规范中定义，而由实现决定。 驱动程序提供微控制器内部  PWM  层（脉冲宽度调制）的初始化和控制功能。 PWM  模块生成具有可变脉冲宽度的脉冲。它允许选择 占空比 和信号 周期 时间。 首字母缩略词和缩写 具有本地范围的首字母缩略词和缩写词不包含在 AUTOSAR 词汇表中。这些必须出现在本地词汇表中。 约束和假设 限制 [ SWS _ Pwm _00001] [ SRS _ Pwm _12386] PWM SWS 不涵盖通用 I/O 上的 PWM 仿真。 仅当 MCAL 驱动程序拥有完整的底层硬件外设（即，其他 MCAL 模块无法访问硬件外设）时，才可实现电源状态控制 API 。 对其他模块的依赖 PWM  依赖于系统 时钟 。因此，系统 时钟 的变化（例如 PLL 开启 -> PLL 关闭）也会影响 PWM 硬件的 时钟 设置。 PWM  驱动器依赖于以下模块： Port 驱动程序： 设置端口 引脚 功能。（PWM141） MCU 驱动程序： 设置预分频器、系统 时钟 和 PLL 。（PWM142） DET ： 开发模式下的默认 错误 跟踪器。（PWM 143） 文档 087_ AUTOSAR _ ECU _ Configuration 包含第4.6章 时钟 树配置，其中详细介绍了向外围设备传送参考 时钟 信号的机制。 代码文件结构 [ SWS _ Pwm _00065] [SRS _ BSW _00346] [SRS _ BSW _00314] PWM SWS 不应定义代码文件结构。 头文件结构 [ SWS _ Pwm _50075] [ ] Pwm . c 应包括 Pwm . h 、 Det . h 和 。 [ SWS _ Pwm _70075] [ ] Pwm _ Irq . c 应包括 Pwm . h 。 需求可追溯性 功能规格 一般行为 [ SWS _ Pwm _0008...
Read more »

AUTOSAR_SWS_PortDriver

图片
AUTOSAR_SWS_ Port Driver 简介和功能概述 本规范规定了 AUTOSAR  基础软件模块 Port  驱动程序的： 功能 API 配置 本驱动程序规范适用于片上： 端口 端口 引脚 该模块应提供 初始化 微控制器整个  Port  结构的服务。 许多 端口 和端口 引脚 可分配给各种 功能 ，例如： General purpose I/O ADC SPI SCI PWM CAN LIN 其他 因此，应对 端口 结构进行 整体 配置和初始化。 这些端口 引脚 的 配置 和 模式 取决于微控制器和 ECU 。 应尽可能高效地将 端口 初始化数据写入每个 端口 。 Port  驱动程序模块应完成在  Dio 驱动程序模块中使用的 端口 结构的整体配置和初始化。 因此， Dio  驱动程序在由  Port  驱动程序配置的 引脚 和 端口 上工作。 在使用  Dio  功能之前，应初始化  Port  驱动程序。 否则， Dio  功能将表现出 未 定义的行为。 下图标识了  Port  驱动程序功能以及 MCAL 软件层中的  Port  驱动程序和  Dio  驱动程序的结构 [1]。 首字母缩略词和缩写 下表总结了  Port  驱动程序中使用的表达式。 约束和假设 Port  驱动程序的限制如下： 用户有责任确保同一系统中的 不 同实体 不 会并行访问同 一 端口 /端口 引脚 ，例如： 两 个任务配置同 一 端口 。 两 个任务配置同 一 引脚。 两 个任务配置同 一 端口 上的 不 同 引脚 。 对其他模块的依赖 其他驱动程序模块可能依赖于  Port  驱动程序，具体取决于 MCU 上各个端口 引脚 的可用功能。例如， MCU   引脚 可能可配置为  Dio  或 SPI   引脚 。因此， Dio  和/或  SPI  驱动程序模块可能依赖于  Port  模块来配置 引脚 以实现所...
Read more »

AUTOSAR_SWS_ECUStateManager

图片
Specification of ECU State Manager 简介和功能概述 Ecu M  模块（如本文档中所述）是一个基本软件模块（参见  AUTOSAR _ TR _ BSW ModuleList.pdf），用于管理 ECU 状态 的常见方面。具体来说， ECU 管理器 模块： 初始化和取消初始化 OS 、 Sch M 和 Bsw M 以及一些基本软件驱动模块 根据请求将 ECU 配置为 休眠 和 关机 管理 ECU 上的所有 唤醒 事件 ECU 管理器模块提供 唤醒 验证协议来区分 “ 真实 ” 唤醒 事件 “ 不稳定 ” 唤醒 事件 此外： 部分 或 快速 启动 其中 ECU 以有限的功能 启动 。 然后根据应用程序的决定，继续逐步 启动 。 交错 启动 ECU 以最低限度 启动 ，然后 启动   RTE 以尽快执行 软件 组件 中的功能。 然后它继续 启动 其他 BSW 和 软件 组件 ，从而交错 BSW 和应用程序功能。 多个 运行 状态 其中 ECU 具有多个 运行 状态。 除其他外，这改进了从 休眠 状态到 运行 状态的频谱概念。 现在可以有一系列 运行 状态，从 经典 运行 （完全 运行 ）到 最深 的 休眠 （处理器 停止 ）。 多核 ECU 启动 、 关机 、 休眠 和 唤醒 在 ECU 的所有核心上协调。 灵活的 ECU 管理采用以下模块提供的通用模式管理设施： RTE  和  BSW  的调度模块（参见   AUTOSAR _ SWS _ RTE .pdf）现在合并为一个模块： 该模块支持自由配置的  BSW  和应用程序模式以及切换模式功能。 BSW  模式管理器模块（参见   AUTOSAR _ SWS _ BSW ModeManager.pdf）： 该模块实现可配置规则和操作列表，以评估切换  ECU  模式的条件并实施必要的操作。 因此，通过灵活的  ECU   管理 ，大多数  ECU   状态 不再在 ECU 管理器 模块中被实现。通常，只有当通用模式 管理 设施在以下情况下不可用时， ECU 管理器 模块才会接管控制...
Read more »

EB - MCAL - MCU

图片
EB  - MCAL MCU MCU （微控制器单元）模块的 配置 。 General 此选项卡为  MCU  模块的 通用 配置 。 Config   Variant ： VariantPreCompile： 仅 预编译 时配置参数。 只有 一 组参数。 VariantPostBuild： 预编译 和 构建 后 时间配置 参数的混合。 只有 一 组参数。 VariantPostBuildSelectable： 预编译 和 构建 后 时间配置 参数的混合。 更多组参数。 General - McuGeneralConfiguration MCU   通用 配置 的 容器。 DevErrorDetect： 预处理器 开关，用于启用默认 错误 检测并向 Det  报告。 开关 DevErrorDetect 将打开或关闭默认 错误 跟踪器 ( Det ) 检测和通知。 默认 错误 的检测可在 预编译 时配置 (ON/OFF)。 #define MCU_DEV_ERROR_DETECT (STD_ON)/(STD_OFF) 将在 Mcu_Cfg .h 文件中生成。 MultiCoreSupport： 此参数全局使能了支持 多核 的可能性。 如果启用此参数，则至少需要定义一个 EcucPartition （在所有变体中）。 McuGetRamStateAPI： 预处理器 开关用于启用/禁用 API Mcu_GetRamState 。 #define MCU_GET_RAM_STATE_API (STD_ON)/(STD_OFF) 将在 Mcu_Cfg .h 文件中生成。 McuInitClockAPI： 如果将此参数设置为 FALSE ，则必须从 MCU 驱动程序禁用 时钟 初始化。 此概念适用于存在一些 一次性 写入 时钟 寄存器且存在 引导加载 程序的情况。 如果将此参数设置为 TRUE ，则 MCU 驱动程序负责 时钟 初始化。 #define MCU_INIT_CLOCK (STD_ON)/(STD_OFF) 将在 Mcu_Cfg .h 文件中生成。 McuNoPLL： 如果 H/W 没有 PLL 或 PLL 电路在开机后无需 S/W 干预即可启用，则此参数应设置为 True 。 在这种情...
Read more »

AUTOSAR_SWS_ICUDriver

图片
AUTOSAR_SWS_ ICU Driver 简介和功能概述 本规范规定了 AUTOSAR 基础软件模块 ICU 驱动程序的功能、 API 和配置。 ICU  驱动程序是一个使用输入捕获单元 ( ICU ) 来解调 PWM 信号、计数脉冲、测量频率和占空比、生成简单中断以及唤醒中断的模块。 ICU  驱动程序提供的服务： 信号 边缘 通知 控制唤醒中断 周期 性信号时间测量 边缘 时间戳，可用于获取非 周期 性信号 边缘 计数 首字母缩略词和缩写 对其他模块的依赖 模块 DET （默认 错误 追踪器） 检测到的 错误 的详细描述可以在第 7.2 章和第 8 章中找到。 模块 MCU ICU 驱动程序依赖于系统 时钟 、预分频器和 PLL 。因此， ICU 定时器刻度的长度取决于模块 MCU 中的 时钟 设置。 ICU 驱动程序不会负责在其 Init 函数中设置配置全局 时钟 、全局 预分频 器和 PLL 的寄存器。这必须由 MCU 模块完成。 ICU 驱动程序仅配置本地（ ICU 外设特定的）时钟、 预分频 器等。 OS （操作系统） ICU 驱动程序使用 中断 ，因此依赖于配置 中断 源的操作系统。它仅提供回调函数。 ICU 驱动程序不会在其 Init 函数中设置 中断 关联的寄存器。 中断 系统的整体分配和激活由操作系统完成。 模块 Port Port 驱动程序负责配置 ICU 用作输入的端口 引脚 。因此，在使用 ICU 功能之前必须初始化  Port  驱动程序。否则 ICU 功能将表现出未定义的行为。 模块 EcuM [ SWS _ Icu _00244] [ ] ICU 驱动程序将向 EcuM 报告唤醒中断。 需求可追溯性 功能规格 背景与理由 为了确保数据一致性，应提供可重入代码。 需求 [ SWS _ Icu _00050] [ ] 不同通道号的  ICU  模块功能应可重入，但以下情况除外： Icu _ Init () Icu _ De Init () Icu _Set Mode () Icu _Get Version Info () [ SWS _ Icu _00149] [ ] 如果在运行时在 不 同的任务或 ISR 中使用了对同一 ICU...
Read more »

EB - MCAL - PWM

图片
EB  - MCAL PWM PWM （脉冲宽度调制）模块的配置。 General 此选项卡为  PWM （脉冲宽度调制）模块的 通用 配置 。 Config Variant： VariantPreCompile：仅 预编译 时配置参数。只有一组参数。 VariantPostBuild：混合 预编译 和 构建后 配置参数。只有一组参数。 General - PwmConfigurationOfOptApiServices PwmConfigurationOfOptApiServices 容器用于存储所有可选 API 的配置。 PwmDeInitApi： 从代码中添加/删除服务 Pwm_DeInit ()。 PwmGetOutputState： 从代码中添加/删除服务 Pwm_GetOutputState ()。 PwmSetDutyCycle： 从代码中添加/删除服务 Pwm_SetDutyCycle ()。 PwmSetOutputToIdle： 从代码中添加/删除服务 Pwm_SetOutputToIdle ()。 PwmSetPeriodAndDuty： 从代码中添加/删除服务 Pwm_SetPeriodAndDuty ()。 PwmVersionInfoApi： 勾选以指示支持  Pwm_GetVersionInfo 。 PwmGetChannelStateApi： 勾选以指示支持  Pwm_GetChannelState 。 PwmEnableTriggerOut： 从代码中添加/删除服务： Pwm_EnableTriggerOut () Pwm_EnableTriggerOut () General - PwmGeneral PwmGeneral 容器用于存储  PWM  的通用配置。 Pwm Multi-Core Enable： 切换启用/禁用 多核 功能。 启用该功能时，需要在 PwmChannelEcucPartitionRef 容器中配置至少一个  ECUC  分区，并且  PwmChannel  容器中的每个  PWM  通道也需要配置至少 一 个  ECUC  分区。 PwmDev...
Read more »