4. Wdg模块核心数据结构：Wdg_ConfigType结构体解析

好，咱们今天来啃一块硬骨头——Wdg模块的配置结构体。说实话，我刚接触AUTOSAR那会儿，看到这些层层嵌套的结构体，头都大了。但后来我发现，只要搞懂了这几个核心数据结构，整个看门狗的配置逻辑就清晰了。

Wdg模块的配置，说白了就是通过一个叫Wdg_ConfigType的结构体来完成的。这个结构体是所有配置的入口，它里面包含了看门狗的所有运行时信息。我习惯把它比作一个“总控台”，你在这个台子上设置好参数，系统启动时就按这个来跑。

4.1 Wdg_ConfigType：配置的总入口

先看这个结构体的定义。在AUTOSAR规范里，它是这么写的：

typedef struct {
    const Wdg_ChannelConfigType   *ChannelConfig;
    const Wdg_TriggerConfigType   *TriggerConfig;
    uint8                         ChannelCount;
    uint8                         TriggerCount;
    Wdg_StatusType                WdgStatus;
    Wdg_TimeoutActionType         TimeoutAction;
} Wdg_ConfigType;

这里有几个关键字段，我一个个说。

ChannelConfig：指向通道配置数组的指针。每个看门狗通道都有自己的配置，比如超时时间、运行模式这些。我见过不少新手直接把这个指针设为NULL，结果系统一跑就崩了。嗯，这里要注意，这个指针必须指向一个有效的配置数组。

TriggerConfig：指向触发配置数组的指针。触发配置是干啥的？它决定了看门狗在什么条件下被触发。比如，你可以配置一个触发事件，当某个任务超时时，看门狗就“咬人”。

ChannelCount和TriggerCount：这两个字段分别指定了通道和触发的数量。为什么要有它们？因为C语言里数组不会自己告诉你长度，你得手动告诉它。我曾经在一个项目里忘了设置ChannelCount，结果看门狗只检查了第一个通道，其他通道全成了摆设……

WdgStatus：当前看门狗的状态。是运行中？还是已超时？还是被关闭了？这个字段会实时更新，方便你调试时查看。

TimeoutAction：超时后的动作。是复位MCU？还是触发一个中断？还是什么都不做只记录日志？这个要根据你的安全需求来定。

4.2 Wdg_ChannelConfig：通道级别的精细控制

接下来看通道配置。每个看门狗通道都可以独立配置，这给了我们很大的灵活性。结构体定义如下：

typedef struct {
    Wdg_ChannelIdType             ChannelId;
    Wdg_ModeType                  DefaultMode;
    Wdg_TimeoutType               Timeout;
    Wdg_TriggeredModeType         TriggeredMode;
    Wdg_SleepModeType             SleepMode;
    boolean                       WakeupSourceEnabled;
} Wdg_ChannelConfigType;

咱们拆开来看：

• ChannelId：通道ID。每个通道必须有唯一的ID，就像人的身份证号。我建议用枚举来定义，清晰又不容易出错。
• DefaultMode：默认模式。系统启动后，看门狗以什么模式运行？是慢速模式？还是快速模式？还是直接关闭？这个要根据你的启动流程来定。
• Timeout：超时时间。这是最关键的参数。设得太短，系统容易误复位；设得太长，又起不到保护作用。我一般会留20%的余量。比如任务周期是100ms，我就设120ms的超时。
• TriggeredMode：触发模式。当看门狗被触发时，它应该怎么响应？是立即复位？还是先通知再复位？这个要看你的安全策略。
• SleepMode：休眠模式。系统休眠时，看门狗要不要继续跑？如果继续跑，谁来喂它？这是个容易踩坑的地方。
• WakeupSourceEnabled：是否允许看门狗作为唤醒源。有些低功耗场景下，看门狗超时可以唤醒系统。但这个功能要慎用，搞不好会频繁唤醒，功耗就上去了。

4.3 Wdg_TriggerConfig：触发条件的精确设定

最后看触发配置。这个结构体定义了看门狗在什么条件下被触发。定义如下：

typedef struct {
    Wdg_TriggerIdType             TriggerId;
    Wdg_TriggerSourceType         TriggerSource;
    Wdg_TriggerActionType         TriggerAction;
    Wdg_TriggerConditionType      TriggerCondition;
    uint32                        TriggerThreshold;
} Wdg_TriggerConfigType;

字段解析：

字段	说明	我的建议
TriggerId	触发ID，唯一标识一个触发条件	用枚举定义，和通道ID区分开
TriggerSource	触发源，比如某个任务、某个中断	明确指定，不要用“自动”这种模糊选项
TriggerAction	触发后的动作，比如复位、中断	根据安全等级选择，ASIL-D建议直接复位
TriggerCondition	触发条件，比如超时、错误计数超限	条件要具体，避免误触发
TriggerThreshold	触发阈值，比如超时次数达到3次才触发	设一个合理的值，太敏感容易误报

你想想看，为什么要有触发配置？因为不是所有的超时都需要立即复位。比如某个非安全相关的任务超时了，你可能只想记录一下日志，而不是让整个系统重启。触发配置就是用来做这种精细化管理的。

4.4 三个结构体的关系

这三个结构体不是孤立的，它们之间是树形关系：

• Wdg_ConfigType是根节点，它包含了通道配置和触发配置的指针。
• Wdg_ChannelConfigType是中间节点，每个通道可以关联多个触发条件。
• Wdg_TriggerConfigType是叶子节点，定义了具体的触发逻辑。

在实际配置时，我习惯先配好触发配置，再配通道配置，最后组装到总配置里。这样逻辑清晰，不容易乱。

举个例子，假设我有一个安全相关的任务，周期是50ms。我会这样配：

/* 触发配置 */
Wdg_TriggerConfigType triggerCfg = {
    .TriggerId = TRIGGER_SAFE_TASK,
    .TriggerSource = TRIGGER_SOURCE_TASK_OVERRUN,
    .TriggerAction = TRIGGER_ACTION_RESET,
    .TriggerCondition = TRIGGER_COND_TIMEOUT,
    .TriggerThreshold = 2
};

/* 通道配置 */
Wdg_ChannelConfigType channelCfg = {
    .ChannelId = CHANNEL_SAFE,
    .DefaultMode = WDGMODE_FAST,
    .Timeout = 60,  /* 留20%余量 */
    .TriggeredMode = TRIGGERED_MODE_RESET,
    .SleepMode = SLEEP_MODE_STOP,
    .WakeupSourceEnabled = FALSE
};

/* 总配置 */
Wdg_ConfigType wdgConfig = {
    .ChannelConfig = &channelCfg,
    .TriggerConfig = &triggerCfg,
    .ChannelCount = 1,
    .TriggerCount = 1,
    .WdgStatus = WDGMODE_FAST,
    .TimeoutAction = TIMEOUT_ACTION_RESET
};

你看，这样配下来，整个看门狗的行为就非常清晰了。哪个通道、什么条件、触发什么动作，一目了然。

好了，这一章的内容就到这儿。记住，配置结构体是看门狗模块的骨架，骨架搭好了，后面的血肉才能长上去。下一章咱们聊聊如何把这些配置应用到实际项目中，到时候我会分享一些调试技巧和踩坑经验。