4、软件安全机制：看门狗定时器（WDT）的实现、内存保护单元（MPU）配置、程序流监控（Block Sequence）技术

各位工程师朋友，咱们今天聊点实在的。多轴系统里，硬件再可靠，软件一旦跑飞，那就是灾难。我见过太多因为软件保护没做到位，导致机械臂撞限位、电机过载烧毁的案例。所以，软件安全机制这块，必须得硬起来。

这一章，我重点讲三个核心武器：看门狗定时器（WDT）、内存保护单元（MPU）、程序流监控（Block Sequence）。说白了，就是给咱们的嵌入式软件装上「三保险」。

4.1 看门狗定时器（WDT）——系统的「心跳监护仪」

看门狗这东西，说白了就是一个独立运行的硬件定时器。你必须在规定时间内「喂狗」，否则它就认为系统挂了，直接触发复位。我习惯把它比作ICU里的心电监护仪——心跳正常时它不吭声，一旦停跳，立刻报警。

4.1.1 喂狗策略——不是随便喂的

我在项目中遇到过一个问题：工程师在主循环末尾统一喂狗，结果某个子任务死循环了，主循环根本跑不到喂狗点。系统一直没复位，因为看门狗还没超时。你想想看，这多危险？

正确的做法是：分层喂狗。每个关键任务执行完后，都去「打卡」一次。我常用的方案是这样的：

• 主循环喂狗：证明调度器还活着
• 通信任务喂狗：证明总线没卡死
• 运动控制任务喂狗：证明轨迹规划还在跑

嗯，这里要注意：喂狗间隔要留有余量。比如看门狗超时设为100ms，你最好每50ms就喂一次。别卡着99ms去喂，万一系统稍微抖一下，就触发了。

4.1.2 窗口看门狗——更高级的玩法

普通看门狗只要求「别超时」，窗口看门狗还要求「别太早」。为什么？因为如果程序跑飞后恰好进入了喂狗代码段，它可能提前喂狗，导致看门狗永远不触发。窗口看门狗规定了一个时间窗口：太早喂不行，太晚喂也不行。

/* 窗口看门狗配置示例（基于STM32） */
void WWDG_Config(void)
{
    // 窗口值：0x7F，计数器上限：0x7F
    // 喂狗必须在计数器值介于 0x40~0x7F 之间时进行
    WWDG->CFR = (0x40 << 7) | WWDG_CFR_WDGTB_0;  // 窗口上限设为64
    WWDG->CR  = 0x7F | WWDG_CR_WDGA;              // 启动看门狗，初始值127
    
    // 喂狗代码必须在窗口期内执行
    // 过早喂狗（计数器 > 64）会触发复位
    // 过晚喂狗（计数器 < 64）也会触发复位
}

#ifdef DEBUG_MODE
    // 不启动看门狗
#else
    HAL_WWDG_Start(&hwwdg);
#endif

4.2 内存保护单元（MPU）——给内存划地盘

MPU 是ARM Cortex-M3/M4/M7等内核提供的硬件保护机制。它能把内存空间划分成多个区域，每个区域可以设置不同的访问权限。说白了，就是给每个任务划一块「自留地」，不允许越界访问。

我见过最惨的案例：一个电机控制任务因为数组越界，把另一个任务的PID参数给覆盖了。结果电机突然反转，差点把机械臂甩出去。如果有MPU保护，这种事故完全可以避免。

4.2.1 MPU 区域配置要点

配置MPU时，我一般遵循这几个原则：

• 代码区：只读+可执行，禁止写操作
• 常量区：只读，禁止执行
• 数据区：可读写，但不同任务的数据区要隔离
• 外设区：按需分配，禁止非授权访问

4.2.2 堆栈溢出保护——MPU的经典应用

堆栈溢出是嵌入式系统最常见的故障之一。我习惯在每个任务的堆栈底部放一个「哨兵区域」，用MPU设置为不可访问。一旦任务堆栈溢出，触碰到这个区域，立刻触发异常。

/* 堆栈溢出保护配置示例 */
void MPU_StackGuard_Config(uint32_t stack_base, uint32_t stack_size)
{
    MPU_Region_InitTypeDef MPU_InitStruct = {0};
    
    // 在堆栈底部设置一个4KB的保护区
    MPU_InitStruct.Enable = MPU_REGION_ENABLE;
    MPU_InitStruct.BaseAddress = stack_base - 0x1000;  // 保护区起始
    MPU_InitStruct.Size = MPU_REGION_SIZE_4KB;
    MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS;  // 禁止任何访问
    MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
    MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
    MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
    MPU_InitStruct.Number = MPU_REGION_NUMBER0;
    MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
    MPU_InitStruct.SubRegionDisable = 0x00;
    MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;
    
    HAL_MPU_ConfigRegion(&MPU_InitStruct);
}

4.3 程序流监控（Block Sequence）——给代码加「安检」

程序流监控，说白了就是检查代码的执行顺序对不对。多轴系统里，任务执行有严格的先后顺序：先采集传感器数据，再计算轨迹，然后输出控制量，最后检查安全状态。如果顺序乱了，后果不堪设想。

我常用的方法是给每个程序块分配一个唯一的ID，然后建立一个「预期执行顺序表」。运行时，每个块执行完后，把自己的ID写入一个状态寄存器。监控任务定期检查这个寄存器，看当前ID是否在预期序列中。

4.3.1 Block Sequence 实现框架

/* 程序流监控核心实现 */
typedef enum {
    BLOCK_ID_INIT = 0x01,
    BLOCK_ID_SENSOR_READ = 0x02,
    BLOCK_ID_TRAJECTORY_CALC = 0x03,
    BLOCK_ID_MOTOR_OUTPUT = 0x04,
    BLOCK_ID_SAFETY_CHECK = 0x05,
    BLOCK_ID_IDLE = 0x06
} BlockID_t;

// 预期执行顺序表
const BlockID_t expected_sequence[] = {
    BLOCK_ID_INIT,
    BLOCK_ID_SENSOR_READ,
    BLOCK_ID_TRAJECTORY_CALC,
    BLOCK_ID_MOTOR_OUTPUT,
    BLOCK_ID_SAFETY_CHECK,
    BLOCK_ID_IDLE
};

volatile BlockID_t current_block_id = BLOCK_ID_INIT;
uint8_t sequence_index = 0;

void BlockSequence_Check(BlockID_t block_id)
{
    // 检查当前块是否在预期位置
    if (block_id != expected_sequence[sequence_index]) {
        // 顺序错误！触发安全动作
        Safety_Shutdown();
        return;
    }
    
    // 更新索引，循环检查
    sequence_index++;
    if (sequence_index >= sizeof(expected_sequence)/sizeof(BlockID_t)) {
        sequence_index = 0;
    }
    
    current_block_id = block_id;
}

// 每个程序块执行完毕后调用
void SensorRead_Task(void)
{
    // ... 传感器读取代码 ...
    
    BlockSequence_Check(BLOCK_ID_SENSOR_READ);
}

4.3.2 超时监控——给每个块加个「闹钟」

光检查顺序还不够，还得检查时间。如果一个块执行时间超过了预期，说明可能卡住了。我通常给每个块设置一个最大执行时间，用硬件定时器来监控。

/* 带超时的Block Sequence监控 */
typedef struct {
    BlockID_t block_id;
    uint32_t max_exec_time_ms;  // 最大执行时间（毫秒）
} BlockTimeConfig_t;

const BlockTimeConfig_t block_time_config[] = {
    {BLOCK_ID_INIT,            100},
    {BLOCK_ID_SENSOR_READ,     50},
    {BLOCK_ID_TRAJECTORY_CALC, 200},
    {BLOCK_ID_MOTOR_OUTPUT,    30},
    {BLOCK_ID_SAFETY_CHECK,    20},
    {BLOCK_ID_IDLE,            500}
};

void BlockSequence_WithTimeout(BlockID_t block_id)
{
    static uint32_t block_start_time = 0;
    uint32_t current_time = HAL_GetTick();
    
    // 检查超时
    if ((current_time - block_start_time) > 
        block_time_config[sequence_index].max_exec_time_ms) {
        // 超时！触发安全动作
        Safety_Shutdown();
        return;
    }
    
    // 检查顺序（同上）
    if (block_id != expected_sequence[sequence_index]) {
        Safety_Shutdown();
        return;
    }
    
    // 更新状态
    sequence_index = (sequence_index + 1) % 
                     (sizeof(expected_sequence)/sizeof(BlockID_t));
    block_start_time = current_time;
    current_block_id = block_id;
}

4.4 三者协同——构建完整的安全防线

WDT、MPU、Block Sequence 这三者不是孤立的。我习惯把它们组合成一个「纵深防御体系」：

• WDT：兜底保护，防止系统完全死锁
• MPU：空间保护，防止内存越界和非法访问
• Block Sequence：逻辑保护，防止程序执行顺序错乱

举个例子：如果MPU检测到堆栈溢出，触发HardFault异常。在异常处理函数中，我不仅会记录错误信息，还会故意停止喂狗。这样WDT在超时后触发系统复位，把系统拉回一个已知的安全状态。同时，Block Sequence 监控到异常后，也会主动触发安全停机。

嗯，这里要强调一点：安全机制本身也要有「自检」功能。我习惯在系统启动时，先测试WDT是否能正常触发复位，MPU是否能正确拦截非法访问，Block Sequence 是否能检测到顺序错误。只有自检通过，才允许系统进入正常运行模式。

好了，这一章的内容就到这里。软件安全机制这块，说白了就是「防患于未然」。别等到出了事故再后悔，那时候代价就大了。