启动参数基础：Bootloader 与启动参数、参数存储位置、参数校验机制

好，咱们进入第二章。这一章要聊的是启动参数——说白了，就是告诉你的固件“该怎么跑”的那一小块数据。

我刚开始做嵌入式那会儿，觉得启动参数不就是几个宏定义嘛，编译时写死就完了。后来被现实狠狠教育了一顿——产品量产之后，客户要改个设备地址，你总不能让人家把 Flash 拆下来重烧吧？嗯，从那以后，我才真正开始认真对待启动参数这件事。

2.1 Bootloader 与启动参数的关系

先理清一个概念：Bootloader 和启动参数到底是什么关系？

Bootloader 是芯片上电后第一个跑的程序。它的任务很简单——初始化硬件、检查启动条件、然后跳转到主固件。但跳转之前，它得知道“往哪跳”、“用什么配置跳”。这些信息，就存在启动参数里。

我习惯把 Bootloader 比作一个“引路人”。它自己不干正事，但它手里拿着地图——地图就是启动参数。地图上写着：主固件在 Flash 的 0x08010000 地址、波特率是 115200、看门狗超时时间是 5 秒。Bootloader 照着地图走，就不会迷路。

这里有个常见的坑：Bootloader 和主固件对启动参数的理解必须一致。比如 Bootloader 认为参数偏移在 0x0800C000，主固件却去 0x0800D000 读——那读出来的就是一堆垃圾数据。我曾经在一个项目里吃过这个亏，两个团队各自写各自的代码，联调时发现设备死活起不来。查了两天才发现，是参数地址没对齐。

2.2 参数存储位置：Flash vs EEPROM

启动参数放哪儿？这得看你的硬件平台和需求。主流选择就两个：Flash 和 EEPROM。当然，有些低成本方案也放 RAM，但一掉电就没了，只能做临时参数。

我整理了一个对比表，你一看就明白：

我个人习惯这样选：

• 量产固件的固定参数（比如设备型号、硬件版本）→ 放 Flash，编译时直接烧进去，不改了。
• 运行时可配置的参数（比如网络 IP、传感器校准值）→ 放 EEPROM，用户改一次就写一次。
• Bootloader 自身的配置（比如启动延迟、固件回滚标志）→ 放 Flash 的专用区域，和主固件区域隔离开。

2.3 参数存储的典型布局

启动参数在 Flash 里怎么排？我画了一张图，帮你理解典型的布局结构：

你看，我把启动参数单独划了一个 4KB 的扇区，紧挨着 Bootloader。为什么是 4KB？因为很多 MCU 的最小擦除单位就是 4KB。参数备份区也是 4KB，用来做双备份——这个后面会细讲。

2.4 参数校验机制

参数存进去了，怎么保证它没被篡改、没被写坏？校验机制就是干这个的。

常用的校验方式有这么几种：

• CRC32：最常用，32 位校验值，检错能力强。我一般用硬件 CRC 模块算，快得很。
• MD5/SHA：安全哈希，但计算量大，嵌入式里用得少。除非你特别在意防篡改。
• 简单累加和：把参数所有字节加起来取低 8 位或 16 位。轻量，但碰撞概率高。
• 双备份 + 比较：存两份参数，读的时候对比。不一致就用备份恢复。

我个人最推荐的做法是：CRC32 + 双备份。CRC32 保证数据完整性，双备份保证写入可靠性。两者互补，基本能覆盖 99% 的异常场景。

来看一个实际的参数结构体定义：

// 启动参数结构体
typedef struct {
    uint32_t magic;          // 魔数，用于识别参数有效性（例如 0xA5A5A5A5）
    uint32_t version;        // 参数版本号
    uint32_t crc32;          // 整个结构体的 CRC32 校验值（包括 magic 和 version）
    
    // 实际参数
    uint32_t baudrate;       // 串口波特率
    uint32_t boot_delay_ms;  // 启动延迟（毫秒）
    uint8_t  device_addr;    // 设备地址
    uint8_t  reserved[3];    // 对齐填充
    uint32_t watchdog_timeout; // 看门狗超时时间
    
    uint32_t end_magic;      // 结束魔数（例如 0x5A5A5A5A）
} BootParams_t;

校验流程是这样的：

1. Bootloader 从 Flash 读取 BootParams_t。
2. 检查 magic 是否为 0xA5A5A5A5，end_magic 是否为 0x5A5A5A5A。
3. 计算从 magic 到 watchdog_timeout 的 CRC32，与存储的 crc32 对比。
4. 如果校验通过，使用参数；如果失败，尝试从备份区读取。
5. 备份区也失败？那就用编译时内置的默认参数，同时标记一个“参数异常”标志。

2.5 参数版本管理

产品迭代过程中，参数结构体可能会变——加个字段、改个类型。这时候版本号就派上用场了。

我习惯的做法：

• 每次修改参数结构体，version 加 1。
• Bootloader 检查版本号，如果发现版本不匹配，就用默认值填充新增字段。
• 旧版参数升级到新版时，Bootloader 负责“迁移”——读取旧版结构，按新布局重新写入。

举个例子：

// 版本 1 的参数
typedef struct {
    uint32_t magic;
    uint32_t version;  // = 1
    uint32_t crc32;
    uint32_t baudrate;
    uint8_t  device_addr;
} BootParams_v1_t;

// 版本 2 的参数（新增了 watchdog_timeout）
typedef struct {
    uint32_t magic;
    uint32_t version;  // = 2
    uint32_t crc32;
    uint32_t baudrate;
    uint8_t  device_addr;
    uint32_t watchdog_timeout;  // 新增字段
} BootParams_v2_t;

Bootloader 里做版本兼容的伪代码：

void load_boot_params(void) {
    BootParams_v2_t params;
    uint32_t stored_version = read_version_from_flash();
    
    if (stored_version == 1) {
        BootParams_v1_t v1;
        read_flash(&v1, sizeof(v1));
        // 迁移到 v2
        params.magic = v1.magic;
        params.version = 2;
        params.crc32 = v1.crc32;
        params.baudrate = v1.baudrate;
        params.device_addr = v1.device_addr;
        params.watchdog_timeout = 5000;  // 默认 5 秒
        // 重新计算 CRC 并写入
        write_flash(¶ms, sizeof(params));
    } else if (stored_version == 2) {
        read_flash(¶ms, sizeof(params));
    } else {
        // 未知版本，使用默认参数
        set_default_params();
    }
}

2.6 本章小结

启动参数看着简单，但坑不少。我总结几个关键点：

• Bootloader 和主固件对参数布局的理解必须一致——地址、大小、校验方式都要对齐。
• Flash 适合存不常改的参数，EEPROM 适合频繁更新的参数。选型时看擦写寿命和容量。
• 校验机制别只靠魔数，CRC32 是底线。双备份是保险。
• 版本号是长期维护的命根子，别偷懒。产品卖三年，参数结构体改个五六版很正常。