1. Bootloader 基础概念

各位同学好，我是你们的嵌入式系统讲师。今天咱们开始《CMS32 Bootloader开发与优化实战》的第一章。说实话，Bootloader 这个概念，很多做了两三年的工程师都未必能讲清楚。我见过不少项目，明明应用层写得挺好，结果 Bootloader 出问题，整机变砖。嗯，咱们从根上把它捋一遍。

1.1 什么是 Bootloader

Bootloader，直译就是“引导加载程序”。说白了，它是一段在芯片上电后最先执行的代码。它的任务很单纯——把真正的应用程序从存储介质里搬出来，放到 RAM 里，然后跳过去执行。

我个人习惯把 Bootloader 比作“嵌入式系统的助产士”。它自己不干重活，但没它，应用代码就起不来。

核心定义：Bootloader 是固化在非易失性存储器（如 Flash）中的一段独立固件，负责初始化硬件、加载并验证应用程序，最终将控制权移交给应用。

你可能会问：为什么不能直接跑应用代码？

原因很简单。芯片上电时，外设时钟、内存控制器、Flash 接口都处于默认状态。直接跑应用，万一 Flash 时序不对，或者 PLL 没锁住，系统直接就挂了。Bootloader 就是那个先帮你把“地基”打好的角色。

特性 Bootloader 应用程序
执行顺序 最先执行 由 Bootloader 跳转
驻留位置 Flash 起始区域（如 0x0000~0x3FFF） Flash 用户区域（如 0x4000 之后）
生命周期 极少更新 频繁升级
核心职责 硬件初始化 + 加载 + 校验 业务功能

1.2 Bootloader 在嵌入式系统中的作用

作用其实就三个字：保、升、稳。

  • 保——保障系统能正常启动。哪怕应用区数据损坏，Bootloader 还能进入恢复模式，等待重新烧录。
  • 升——支持固件远程升级（OTA）。没有 Bootloader，每次升级都得开壳接烧录器，这在产品量产阶段是灾难。
  • 稳——做启动自检。检查 CRC、检查版本兼容性，避免因为 Flash 位翻转导致跑飞。

个人经验：我曾经在一个智能表计项目里，因为 Bootloader 没做 Flash 校验，结果 OTA 升级时网络中断，写了一半的固件导致设备死机。后来我强制要求 Bootloader 必须做“双备份 + CRC 校验”，从那以后再没出过类似问题。

你想想看，如果 Bootloader 只做一件事，那就是“让系统永远有救”。哪怕应用代码全坏了，Bootloader 还在，就能通过串口、CAN 或无线把新固件灌进去。

1.3 CMS32 启动流程概述

CMS32 是国民技术基于 ARM Cortex-M0+ 内核的 MCU 系列。它的启动流程，其实和标准 Cortex-M 流程一脉相承，但有一些细节值得注意。

咱们先看一张整体流程图：

CMS32 启动流程总览 上电复位 从 0x0000 加载向量表 取 MSP 初始值 + Reset_Handler 地址 跳转 Reset_Handler 检查升级标志 进入 Bootloader 升级模式 跳转至应用程序入口 硬件自动完成 无需软件干预 CMS32 默认映射 0x0000 = Flash 首地址

这张图把 CMS32 从复位到最终进入应用或 Bootloader 的完整路径画出来了。咱们拆开细说。

1.3.1 硬件复位与向量表加载

芯片上电后，硬件自动做三件事：

  1. 从地址 0x00000000 读取栈顶指针（MSP 初始值）
  2. 从地址 0x00000004 读取复位向量（Reset_Handler 地址）
  3. 跳转到 Reset_Handler 执行

这里有个坑。CMS32 的 Flash 起始地址默认就是 0x0000，但如果你做了 IAP（在应用编程），Bootloader 和应用可能共用同一个向量表区域。我曾经遇到一个项目，Bootloader 升级后忘记重映射向量表，结果中断全跑飞了。嗯，这个后面讲中断向量表重映射时会细说。

1.3.2 Reset_Handler 做了什么

Reset_Handler 是 CMS32 启动的核心。它通常完成：

  • 关闭看门狗（如果硬件默认开启）
  • 初始化系统时钟（从 HSI 切换到 HSE + PLL）
  • 初始化 .data 段（从 Flash 拷贝到 SRAM）
  • 清零 .bss 段
  • 调用 SystemInit()（CMSIS 标准接口）
  • 最后调用 main()

注意：CMS32 的 SystemInit() 里默认会配置 Flash 等待周期。如果你超频跑（比如 72MHz 以上），必须手动调整等待周期，否则 Flash 读取会出错。我见过有人把 HCLK 配到 96MHz 但等待周期还是 0，结果程序跑几步就 HardFault。

1.3.3 Bootloader 的介入时机

在 Reset_Handler 执行完基础初始化后，通常会在跳转到 main() 之前，或者 main() 的最开头，检查是否需要进入 Bootloader 模式。

判断条件一般有三种：

判断方式 典型实现 适用场景
GPIO 电平检测 上电时读取某个引脚电平 工厂烧录、调试
Flash 标志位 在固定地址写一个魔数（如 0xA5A5A5A5） OTA 升级请求
应用区有效性检查 CRC 校验失败则进入 Bootloader 异常恢复

我个人习惯用“Flash 标志位 + 应用 CRC”双重判断。先看标志位，如果没置位，再看应用区 CRC 是否正常。这样既支持主动升级，也能自动进入恢复模式。

1.3.4 跳转到应用程序

当 Bootloader 决定启动应用时，需要做两件事：

  1. 关闭所有外设中断（避免跳转后中断状态混乱）
  2. 修改向量表偏移寄存器（VTOR）指向应用区的向量表
  3. 获取应用区的栈顶指针和 Reset_Handler 地址
  4. 用汇编指令跳转

跳转代码其实很短，我贴一段典型的实现：

/* CMS32 跳转到应用程序 */
void jump_to_app(uint32_t app_addr)
{
    uint32_t msp_value;
    uint32_t reset_handler;
    void (*app_entry)(void);

    /* 1. 关闭全局中断 */
    __disable_irq();

    /* 2. 关闭所有外设中断（具体外设逐个关） */
    /* ... */

    /* 3. 从应用区首地址取栈顶指针 */
    msp_value = *(volatile uint32_t *)app_addr;

    /* 4. 从应用区首地址+4取复位向量 */
    reset_handler = *(volatile uint32_t *)(app_addr + 4);

    /* 5. 设置向量表偏移 */
    SCB->VTOR = app_addr;

    /* 6. 设置主栈指针 */
    __set_MSP(msp_value);

    /* 7. 跳转 */
    app_entry = (void (*)(void))reset_handler;
    app_entry();
}

避坑指南：我曾经在跳转前忘记关 SysTick 中断，结果应用启动后 SysTick 还在用 Bootloader 的周期配置，导致时间基准全乱。后来我养成了习惯——跳转前把所有定时器、DMA、中断都复位到默认状态。

1.4 本章小结

咱们这一章把 Bootloader 是什么、为什么需要它、以及 CMS32 从复位到启动应用的完整流程都过了一遍。核心就三句话：

  • Bootloader 是系统启动的第一段代码，负责“保底”和“升级”
  • CMS32 的启动流程遵循 Cortex-M 标准，但要注意 Flash 等待周期和向量表重映射
  • 跳转应用前必须关中断、清状态、设 VTOR
← 上一章 📖 返回目录 下一章 →