One article easily understands the Watchdog protocol stack of AUTOSAR

One article easily understands the Watchdog protocol stack of AUTOSAR (Part 1)

foreword

First of all, I would like to ask you a few questions, you know:

• What is the basic function of watchdog?
• Watchdogs can be divided into two categories in the general sense?
• Is the watchdog software operating mechanism based on the AUTOSAR architecture?
• How do watchdogs relate to functional safety?
• What pitfalls need to be avoided in the process of using the watchdog?

Today, let's explore and answer these questions together. To make it easier for everyone to understand, the following is an outline of the topics of this article:

---

text

Basic functions of Watchdog

As we all know, Watchdog, the Chinese name is watchdog, is to realize the system reset operation can be automatically completed to ensure the continuous use of the entire function when the system is abnormal when the device is unattended.

The watchdog function is necessary for safety-critical systems, but it is also necessary for non-safety-critical systems.

Why do you say that? The reason is that the software running in the hardware world will be affected by various external factors, such as the aging and damage of the hardware itself, external electromagnetic interference, etc., which may lead to unpredictable behaviors during the running of the program, and these unpredictable If there is no watchdog for the behavior, then it will be over. If your device is in a desert area where there are few people, it will undoubtedly increase a lot of unnecessary maintenance costs.

For many components used in automobiles, in view of the harsh environment of automobiles, the software in various ECUs may be affected by environmental factors such as external electromagnetic interference, high temperature, etc., resulting in the phenomenon of "running away" or "crash" of the program. If there is a watchdog at this time, it can actively trigger the system reset mechanism to ensure that it can be used normally again, instead of just watching it being sent to a 4S shop for repairs, affecting product reputation or adding unnecessary after-sales maintenance. cost.

Based on the implementation logic of the watchdog, we can generally divide the watchdog into hardware watchdog and software watchdog.

As the name implies, the hardware watchdog is to realize the watchdog function through the mechanism of the hardware itself, and its essence is also realized through the principle of the timer, but at this time the role of the software is only to enable the timer, and the change and update of the timer itself It is completed by the hardware itself; the software watchdog is to enable and update the entire timer completely by software. Of course, the software is also completed by the timer, but only in an indirect way.

hardware watchdog

As mentioned above, the hardware watchdog relies on its own timer to complete the watchdog function, commonly known as " hard dog ". Common hardware watchdogs include the watchdog built into the MCU, the watchdog embedded in the PMIC, and the independent external watchdog.

As for which hardware watchdog to choose, it depends entirely on the needs of your own system settings, and it cannot be the same. However, the following two points need to be considered when using the hardware watchdog:

• Whether the maximum timeout time of the hardware watchdog can meet the system design requirements, if the timeout time is too small, it will lead to the instability of the whole system and trigger the watchdog by mistake;
• Whether the hardware watchdog can be turned off, for key security systems, it is generally required that once the watchdog is turned on, it will not be allowed to be turned off;
• The hardware watchdog system is powered on or off by default. If the watchdog is turned on by default, then for the software, it is necessary to consider feeding or resetting the watchdog after the chip is powered on. At the same time Design a physical closing action before flashing software or debugging software.
• Which way does the hardware watchdog use to feed the dog, such as feeding the dog through GPIO, IIC or SPI communication methods, because different communication dog feeding methods have requirements for the hardware resources of the chip, so it is relatively simple and reliable as far as possible The communication method can be used to feed the dog. Little T thinks that GPIO is better than IIC, and IIC is better than SPI.

The following figure 1 lists the hardware watchdogs with different communication methods on the market:

• GPIO feeding dog hardware watchdog:

• IIC feeding dog hardware watchdog:

• SPI feeding dog hardware watchdog:

Figure 1 Various dog feeding methods hardware watchdog

software watchdog

As mentioned above, the software watchdog belongs to the realization of the watchdog function through the software timer, commonly known as " soft dog ". The time of the software watchdog essentially also needs to rely on the hardware timer on the hardware peripheral.

For example, we usually use the ostick method to perform the timing function. A task runs the main program whose timer monitored by the soft dog keeps decreasing, and other task programs reset the timer. If the software monitors the main program of a task If the timer is reset to zero, then it can be judged that other tasks have not been executed normally. At this time, the watchdog function can be realized by actively resetting.

Generally speaking, the priority of the main task of running the soft dog should not be set lower than the priority of the monitored task. It is used together with the hardware watchdog. Generally, the main task of the soft dog and the hardware watchdog feed the dog. The main task is put into the same task, so that the hierarchical relationship shown in Figure 2 below can be guaranteed:

Figure 2 Hierarchical relationship between soft dogs and hard dogs

The above picture is used as a practical case for your reference only, and the specific implementation method can be determined according to the project requirements. In the figure, the priorities of Task A, B, and C are all lower than those of Task D. If you feed a hard dog in Task D, then it is possible that Task D is running normally, while other tasks hang up and the system is always running normally. The protection function of the hardware watchdog cannot be achieved.

Therefore, in order to prevent the task priority of feeding the hard dog from being too high, causing other low-priority tasks to hang and be undetectable, it is necessary to add a soft dog to protect the low-priority tasks.

Through Task A, B, C to reset the respective counters, the reset value setting needs to be determined in conjunction with the maximum running time and cycle of the respective tasks, and Task D is running the soft dog monitoring main body to realize each Task For the decrement action of the counter, if all task counters are not equal to 0 within the reset value time, it means that other low-priority tasks are running normally. At this time, the hard dog can be fed through GPIO, IIC or SPI normally, otherwise If any counter is 0, then it is necessary to stop feeding the dog or actively trigger the reset behavior.

AUTOSAR Watchdog protocol stack introduction

In fact, for the above-mentioned application scenarios where soft dogs and hard dogs are used in combination, the AUTOSAR architecture has also considered its standardization in the entire Watchdog protocol stack. Therefore, in the actual project development process, you can further learn through the following Understand the working principle and usage of the AUTOSAR-based Watchdog protocol stack.

Figure 3 below shows the software-level topology diagram of the AUTOSAR architecture for the Watdog protocol stack:

Figure 3 Watchdog protocol stack under the AUTOSAR architecture

As shown in Figure 3 above, under the AUTOSAR architecture, the Watchdog protocol stack can be divided into the following three software modules:

• Watchdog Driver : used to implement register operation and control for hardware watchdog, can be divided into MCU internal watchdog (Internal Watchdog) and external watchdog (External Watchdog), the external watchdog can be through GPIO or IIC or SPI to realize dog feeding;
• Watchdog Interface : Watchdog If is part of the entire Watchdog Stack, and its main function is to realize the connection between the upper-level Watchdog Manager and the underlying Watchdog Driver. Of course, there can be multiple underlying Watchdog Drivers connected to it, which is more common in multi-core designs.
• Watchdog Manager : The Watchdog Manger module is the service layer in the entire watchdog protocol stack. The main function of the Watchdog Manager is to be responsible for the correctness of the entire program execution, and trigger the corresponding hardware watchdog's dog feeding action, which plays the role of the entire monitoring core role.

The functions of the entire AUTOSAR Watchdog Stack can be realized through the three modules under the above-mentioned AUTOSAR architecture. Next, Xiao T will explain these three modules in detail to ensure that we can have a clearer understanding of these three modules. , better applied to actual combat.

Understanding the Watchdog Driver module

This module provides functions such as initializing the hardware watchdog, changing the operation mode, and setting the way to trigger the watchdog to feed the dog . At the same time, according to whether the watchdog is located inside the chip, the watchdog located inside the chip can be called an internal watchdog, and the watchdog located outside the chip can be called an external watchdog.

Regardless of whether it is an internal watchdog or an external watchdog, the watchdog-driven API used by the Watchdog Driver should always be consistent . It’s just that for the internal watchdog, its driver belongs to the MCAL layer, while for the external watchdog it belongs to the ECU hardware abstraction layer. The external watchdog driver needs to call other drivers in MCAL to realize the dog feeding action, such as GPIO, IIC Or drive such as SPI.

internal watchdog

As mentioned above, the internal watchdog is the hardware watchdog inside the chip. The driver of the internal watchdog is generally provided by the chip manufacturer. However, it is worth noting that before using the internal watchdog of the chip, it is necessary to confirm Whether the reset action is a cold reset, whether there are scenarios such as incomplete reset, otherwise the purpose of security monitoring may not be achieved.

Since the internal watchdog is related to the chip itself, if there is a problem with the hardware of the chip itself, it may cause the internal watchdog itself to fail, thus presenting itself in a predicament that cannot be guaranteed. Therefore, to a certain extent, for key security systems, only It is not safe to use the internal watchdog, and it is still necessary to rely on the external watchdog to ensure its functional safety.

external watchdog

The external watchdog is a watchdog located outside the protected chip. The watchdog can be an independent hardware watchdog, that is, this kind of watchdog only provides watchdog functions, but it is generally QM level, and there is another type It is the watchdog integrated in the PMIC. This kind of watchdog can generally meet the requirements of ASIL B or ASIL D functional safety level.

External watchdogs are generally necessary for critical safety systems. In a sense, internal watchdogs are actually dispensable, and external watchdogs are crucial.

Watchdog Control Mode

In the AUTOSAR architecture, for the Watchdog Driver, the watchdog control mode is defined to have the following three modes:

• Off Mode : Indicates that the watchdog is off. For key safety systems, it cannot be switched to Off. That is, once it is turned on, it cannot be turned off;
• Slow Mode : Indicates a long-time dog feeding window for the watchdog, which is generally used in the system startup initialization process;
• Fast Mode : Indicates the normal dog feeding window feeding mode of the watchdog, which is used during the normal operation of the system.

Watchdog feeding timing

As shown in Figure 4 below, there are three types of function call scenarios for Watchdog initialization, triggering watchdog feeding and changing watchdog mode.

• Watchdog initialization : call the function Wdg_Init through the EcuM module to complete the initialization configuration of Watchdog;

• Trigger the watchdog to feed the dog : call the function WdgIf_SetTriggerCondition provided by the WdgIf module through the WdgM module to trigger the underlying driver to perform the dog feeding action;

• Change the watchdog mode : call the function WdgIf_SetMode provided by the WdgIf module through the WdgM module to change the watchdog mode.

Figure 4 Timing diagram of watchdog initialization, triggering watchdog and setting watchdog mode

Figure 5 below is a timing diagram of the interaction between the Wathdog driver and the underlying watchdog hardware. From the figure below, it can be seen that WdgIf_SetTriggerCondition will continue to call the function Wdg_SetTriggerCondition in the Wdg driver to realize the dog feeding action.

Figure 5 The timing relationship between the watchdog driver and the underlying hardware watchdog interaction

Common function API and configuration parameters

In order to make it easier for everyone to quickly call the key functions of this module and have a clearer understanding, Xiao T made the following summary in the form of a table:

Figure 6 Description of the common function interface of the watchdog driver module

Figure 7 Description of common configuration parameters of the watchdog driver module

Understanding the Watchdog If module

Watchdog If module function description

The full name of the Watchdog If module is the Watchdog Interface interface. As an abstraction of the underlying Watchdog Driver, the interface is to realize the decoupling between the underlying hardware and software.

The basic function of this module is only used as the abstraction layer of the underlying driver to realize the interaction between the underlying watchdog driver and the upper layer watchdog management module. The characteristics of the underlying watchdog driver, such as window control and time period, cannot be set through Watchdog If module to complete.

If more than one watchdog driver is managed by the upper Watchdog Manager, then DeviceIndex will need to be checked, and if there is an error, it needs to be reported in time.

Common function API and configuration parameters

In order to make it easier for everyone to quickly call the key functions of this module and have a clearer understanding, Xiao T made the following summary in the form of a table:

Figure 8 Description of commonly used functions of the Watchdog If module

Figure 9 Description of common configuration parameters of the Watchdog If module

Understanding the Watchdog Manager module

How the Watchdog Manager module works

Watchdog Manager can be understood as an application layer soft dog mechanism, and the objects monitored by this software mechanism are called "monitoring entities". Its monitoring methods can be divided into the following three types:

• Alive Supervision: Used to monitor whether periodic tasks run periodically;

• Deadline Supervision: Used to monitor whether the running time of event-based tasks has timed out;

• logical supervision: used to monitor whether the execution timing of tasks is correct;

  By marking the corresponding Checkpoint in each monitoring entity, each monitoring entity can have one or more Checkpoints. The Checkpoint and its conversion relationship inside a monitoring entity is called an inner graph. If it is from a different monitoring entity Checkpoint and its The conversion relationship is an external graph .

The above three monitoring mechanisms are used to monitor each entity, and each monitored entity may have one or more or even all three mechanisms enabled, depending on specific requirements. Based on the monitoring results of the above three monitoring mechanisms, each monitoring entity can be calculated, which is called Local Status .

When the status of each monitoring entity is determined, the monitoring result of the entire MCU can be finally determined, and this final status is called Global Status .

Specific workflow of Watchdog Manager:

S1: The Watchdog Manager module is responsible for setting the trigger condition of Watchdog Driver feeding the dog through Watchdog If and Watchdog Driver. The trigger condition is to reset the Counter value through the function interface of Watchdog Manager;

S2: If the Counter is not 0, then the Watchdog Driver will feed the dog once and decrease the Counter value by one;

S3: If the Counter value is not reset by the Watchdog Manager in time, it will be reduced to 0, then the Watchdog Driver will stop feeding the dog, so the watchdog will trigger a system reset, otherwise continue to execute S2;

It is worth noting that if the trigger conditions are not met and the dog cannot be fed normally, there are two ways to feed the dog in the system:

• Wait for the watchdog timeout reset: stop feeding the dog, wait for the watchdog timeout reset;
• Actively trigger system reset immediately: when an error occurs in Watchdog Manager, it can actively trigger system reset;

The above two reset methods can coexist, and which reset method can be specifically executed can be executed as required.

When using the Watchdog Manager, the initialization of the Watchdog Driver cannot be completed by the Watchdog Manager, but should be completed by the EcuM module, and the initialization of the Watchdog Manager should be performed after the OS is turned on.

Alive Supervision

As mentioned above, for the monitoring entity of periodic tasks, the number of executions of the corresponding monitoring entity within a given time range is determined. This monitoring mechanism can be used to detect that certain periodic tasks run too frequently or too little.

In the process of using AliveSupervision, there are the following points to note:

• For a monitoring entity, if the Alive monitoring mechanism is used, there should be no more than one checkpoint. Currently, only one Checkpoint is supported.
• Adjust and use according to the following four parameters to determine how Alive Supervision monitors and how effective it is.

Deadline Supervision

As mentioned above, for the monitoring entity of non-periodic tasks, the time between the two checkpoints corresponding to the monitoring entity should be within a certain range, so that it can be judged whether the time between the two checkpoints is within the set minimum value and between the maximum values.

In the process of using Deadline Supervision, there are the following points to note:

• This monitoring mechanism can only monitor delays, but cannot detect timeouts, such as End Checkpoint not being executed;
• The monitoring mechanism does not support nesting, such as start 1, start2, end2, end1;
• The following figure is the logic diagram of Deadline Supervision. By calculating the time difference between two Checkpoints, it can be determined whether the set requirements are met.

Logic Supervision

As mentioned earlier, logic supervision is used to realize whether the program flow running timing is correct, which is very important for ECUs that meet functional safety. By checking whether the switching relationship between checkpoints in the actual running process meets the set The checkpoint switches the relationship to judge. If it is not within the set checkpoint relationship, an error will be reported. If both are within the checkpoint, then everything is running normally.

The following figure shows the topology of Logic Supervision. By identifying whether the switching relationship between two checkpoints belongs to the statically configured switching relationship group, it is determined whether the normal sequence behavior is executed.

As shown in the figure below, it is the operating mechanism of the entire Watchdog Manager module:

Mechanism of the Watchdog manager module

Based on the above figure, we can draw the following important conclusions:

• The monitoring entity using Alive Supervision, the judgment result is obtained in WdgM_Mainfunction ;
• For monitoring entities using Deadline Supervision or Logical Supervision, the judgment result is obtained in the function WdgM_CheckpointReached ;
• Each monitoring entity has a Local Status, and the final result of the Local Status will determine the Global Status of the final ECU. Therefore, it is necessary to figure out how the Local Status of WdgM changes. Figure 10 below shows the Local Status state machine:

Figure 10 Local Status change state machine/center> in Watchdog manager

Through the above Figure 10, we can draw the following basic conclusions:

• Execution sequence 10 as shown in the figure, after executing the WdgM_Init function, the Local Status of each monitoring entity will be changed to WDGM_LOCAL_STATUS_OK ;
• Execute sequence 11 as shown in the figure, if there are monitoring entities that are not referenced by WdgMInitialMode during the execution of WdgM_Init , the values ​​of these monitoring entities will be set to WDGM_LOCAL_STATUS_DEACTIVATED by default ; at the same time, the WdgMInitialMode of the monitoring entities referenced by WdgMInitialMode is not set to WDGM_LOCAL_STATUS_OK , then it will also be set to WDGM_LOCAL_STATUS_DEACTIVATED .
• If the monitoring results of all monitoring entities are OK and the Local Status of the monitoring entity is WDGM_LOCAL_STATUS_OK, sequence 1 will be executed ;
• If the status of a monitoring entity is WDGM_LOCAL_STATUS_OK, but the result of its corresponding Alive Supervision or Deadline Supervision or Logical supervision is incorrect, then the state machine will execute sequence 2 ;
• Since the results of the Alive Supervision of the monitoring entity are allowed to have error thresholds, if all the Deadline Supervision or Logical supervision results of a monitoring entity are correct, but there is a certain Alive Supervision result that is wrong but does not exceed the set error When the threshold value is reached, then sequence 3 will be executed to enter WDGM_LOCAL_STATUS_FAILED.
• If the state of the current monitoring entity (SE) is in the WDGM_LOCAL_STATUS_FAILED state, except that the results of Deadline Supervision or Logical supervision are all correct, but there is at least one Alive Counter error that does not exceed the error threshold, then sequence 4 will be executed ;
• If SE Local Status == WDGM_LOCAL_STATUS_FAILED state, the Alive Supervision of the SE is correct, and the current number of failures is greater than 1, and the results of the corresponding Deadline Supervision or Logical supervision are all correct, then it will continue to remain in the WDGM_LOCAL_STATUS_FAILED state, but will Decrease the number of errors by 1, such as sequence 4 ;
• If SE Local Status == WDGM_LOCAL_STATUS_FAILED state, the Alive Supervision of the SE is correct, and the current number of failures is equal to 1, and the results of the corresponding Deadline Supervision or Logical supervision are all correct, then the state will be switched to WDGM_LOCAL_STATUS_OK in WdgM_MainFunction state, and reduce the number of errors to 0 at the same time, such as sequence 5 ;
• If SE Local Status == WDGM_LOCAL_STATUS_FAILED state, the Alive Supervision of the SE is incorrect, and the number of current failures is greater than its threshold, or at least one corresponding Deadline Supervision or Logical supervision result is incorrect, then the status will be displayed in WdgM_MainFunction Switch to the WDGM_LOCAL_STATUS_EXPIRED state, such as sequence 6 ;
• If SE Local Status == WDGM_LOCAL_STATUS_OK state, and WdgM_SetMode is executed to switch state to OFF state, then the state machine state will be changed to WDGM_LOCAL_STATUS_DEACTIVATED state, such as sequence 7 ;
• If SE Local Status == WDGM_LOCAL_STATUS_FAILED state, and WdgM_SetMode is executed to switch state to suppressed state, then the state machine state will be changed to WDGM_LOCAL_STATUS_DEACTIVATED state, such as sequence 8 ;
• If SE Local Status == WDGM_LOCAL_STATUS_DEACTIVATED status, WdgM_CheckpointReached and WdgM_MainFunction functions will not start any monitoring function, such as sequence 8 ;
• If SE Local Status == WDGM_LOCAL_STATUS_DEACTIVATED state, and execute WdgM_SetMode to switch state to active state at the same time, then the state machine state will be changed to WDGM_LOCAL_STATUS_OK state, such as sequence 9 ;
• When switching from other states to the WDGM_LOCAL_STATUS_EXPIRED state, Watchdog Manager provides a certain time retention mechanism that allows you to do some special operations, such as setting the watchdog mode or writing NVM data, reset reasons, etc.

After talking about the transformation conditions of the Local Status state machine of the monitoring entity above, let's take a closer look at the Global Status state machine of the monitoring entity, which is shown in Figure 11 below:

Figure 11 Global Status change state machine in Watchdog manager

As shown in Figure 11 above, there is only one Global Status in Watchdog Manager for the entire monitored software. The specific rules for the change of the state machine are as follows:

• If the WdgM_Init function is executed, then Global Status == WDGM_GLOBAL_STATUS_OK, such as sequence 13;
• If the Global Status == WDGM_GLOBAL_STATUS_OK stage, the function WdgM_DeInit is executed, then it will cause the state machine to switch: Global Status == WDGM_GLOBAL_STATUS_ DEACTIVATED, such as sequence 14;
• If Global Status == WDGM_GLOBAL_STATUS_OK, and Local Status of all SEs == WDGM_LOCAL_STATUS_OK or WDGM_LOCAL_STATUS_DEACTIVATED, then Global Status will remain unchanged, such as sequence 1;
• If Global Status == WDGM_GLOBAL_STATUS_OK, there is at least one SE with Local Status == WDGM_LOCAL_STATUS_FAILED, and there is no SE result == WDGM_LOCAL_STATUS_EXPIRED, then the Global Status will switch to the WDGM_GLOBAL_STATUS_FAILED state, such as sequence 2;
• If Global Status == WDGM_GLOBAL_STATUS_OK, there is at least one SE with Local Status == WDGM_LOCAL_STATUS_EXPIRED and the WdgMExpiredSupervisionCycleTol setting is greater than 0, then the Global Status will switch to the WDGM_GLOBAL_STATUS_EXPIRED state, such as sequence 3;
• If Global Status == WDGM_GLOBAL_STATUS_OK, there is at least one SE with Local Status == WDGM_LOCAL_STATUS_EXPIRED and the WdgMExpiredSupervisionCycleTol setting is equal to 0, then the Global Status will switch to the WDGM_GLOBAL_STATUS_STOPPED state, such as sequence 4;
• If Global Status == WDGM_GLOBAL_STATUS_FAILED, there is at least one SE with Local Status == WDGM_LOCAL_STATUS_FAILED and there is no SE equal to WDGM_LOCAL_STATUS_EXPIRED, the Global Status status will remain unchanged, such as sequence 5;
• If Global Status == WDGM_GLOBAL_STATUS_FAILED, and all SEs == WDGM_LOCAL_STATUS_OK or WDGM_LOCAL_STATUS_DEACTIVATED, then Global Status will switch to WDGM_GLOBAL_STATUS_OK, such as sequence 6;
• If Global Status == WDGM_GLOBAL_STATUS_FAILED, there is at least one SE with Local Status == WDGM_LOCAL_STATUS_EXPIRED and the WdgMExpiredSupervisionCycleTol setting is greater than 0, then the Global Status will switch to WDGM_GLOBAL_STATUS_EXPIRED, such as sequence 7;
• If Global Status == WDGM_GLOBAL_STATUS_FAILED, there is at least one SE with Local Status == WDGM_LOCAL_STATUS_EXPIRED and WdgMExpiredSupervisionCycleTol is set equal to 0, then Global Status will switch to WDGM_GLOBAL_STATUS_STOPPED, such as sequence 8;
• If Global Status == WDGM_LOCAL_STATUS_EXPIRED, and the timeout Counter count is less than the value set by WdgMExpiredSupervisionCycleTol, then its status will remain unchanged, such as sequence 9;
• If Global Status == WDGM_LOCAL_STATUS_EXPIRED, and there is at least one SE whose count is greater than WdgMExpiredSupervisionCycleTol, its state will switch to WDGM_GLOBAL_STATUS_STOPPED. In this state, the watchdog driver will stop feeding the dog and wait for the watchdog timeout reset, such as sequence 10;
• If Global Status == WDGM_GLOBAL_STATUS_STOPPED, its status will remain unchanged, such as sequence 11;
• If the call function WdgIf_SetMode fails, it will also cause the Global Status to switch to the WDGM_GLOBAL_STATUS_STOPPED state, such as sequence 12.

Common function API and configuration parameters

In order to make it easier for everyone to quickly call the key functions of this module and have a clearer understanding, Xiao T made the following summary in the form of a table:

Watchdog and functional safety relationship

In ISO26262, program flow monitoring is the most important item. Through program flow monitoring, errors that may violate the design intention during software operation can be found, so that corresponding measures can be taken to ensure driving safety.

In the AUTOSAR software architecture, the monitoring function of the program flow is mainly realized by the Watchdog protocol stack, which includes the WdgM module, the WdgIf module and the Wdg driver module from top to bottom. For the application layer, these three modules are given to the application through RTE The layer provides interface services, thereby realizing the purpose of monitoring the application layer software at the bottom layer.

Watchdog practical experience

• After the watchdog initialization is completed through the EcuM module, the initial value of the watchdog Counter set at the beginning can cover the time from the initialization of the Watchdog Driver to the initialization of the Watchdog Manager as much as possible, otherwise it is easy to cause the dog to time out.
• Before the OS shutdown, the Watchdog Manager needs to be set to a larger Timeout value during the de-initialization process to ensure that it can cover the process of the Watchdog Manager de-initialization to the system power down or reset again.
• If the ECU supports sleep mode, if the watchdog is still active when the ECU is in sleep, then the watchdog feeding operation needs to be completed in the EcuM module.
• In the two stages of system initialization and dormancy, it is important to consider whether the watchdog may time out. If the underlying hardware cannot feed the dog in time, it will have a major impact on the system.

Since the entire watchdog protocol stack has a lot of content, in order to facilitate everyone’s absorption, Xiao T divides the explanation of the entire Watchdog protocol stack into two parts. The next part will focus on the internal processing logic of the above three monitoring methods. Thank you for your attention. .

A dog timed out.

• Before the OS shutdown, the Watchdog Manager needs to be set to a larger Timeout value during the de-initialization process to ensure that it can cover the process of the Watchdog Manager de-initialization to the system power down or reset again.
• If the ECU supports sleep mode, if the watchdog is still active when the ECU is in sleep, then the watchdog feeding operation needs to be completed in the EcuM module.
• In the two stages of system initialization and dormancy, it is important to consider whether the watchdog may time out. If the underlying hardware cannot feed the dog in time, it will have a major impact on the system.

Since the entire watchdog protocol stack has a lot of content, in order to facilitate everyone’s absorption, Xiao T divides the explanation of the entire Watchdog protocol stack into two parts. The next part will focus on the internal processing logic of the above three monitoring methods. Thank you for your attention. .

For more exciting and practical content of AUTOSAR, everyone is welcome to pay attention to the official account: My opinion on ADAS and ECU!