1. 项目概述与核心价值在嵌入式开发领域尤其是基于NXP Kinetis系列MCU的项目中如何高效、可靠地完成固件更新是每个工程师都会面临的挑战。无论是产品出厂前的批量烧录还是产品部署到现场后的远程升级一个稳定、灵活的Bootloader引导加载程序都是不可或缺的基石。今天我想和大家深入聊聊Kinetis MCU的Flashloader这不仅仅是一个“烧录工具”更是一个连接开发环境与最终硬件产品的桥梁。Flashloader是MCU Bootloader的一种具体实现它的核心价值在于允许我们将一个可执行的引导程序加载到MCU的RAM中运行。这种设计巧妙地将用户应用程序固定在Flash存储器的起始地址实现上电自动启动而Bootloader本身则作为“一次性编程助手”在需要更新固件时才被激活。对于像KM35Z512这类内部没有ROM Bootloader的芯片由NXP提供的Flash Bootloader源码就显得尤为重要它赋予了开发者从零构建定制化引导流程的能力。本文将从一个实践者的角度拆解Flashloader的配置、编译、使用全流程并分享我在实际项目中积累的一些关键技巧和避坑经验希望能帮助大家更顺畅地驾驭这项技术。2. Kinetis Bootloader体系深度解析在动手配置之前我们必须先理解NXP为Kinetis MCU提供的Bootloader“全家桶”。不同的配置对应着不同的应用场景和硬件限制选型错误可能会导致后续开发事倍功半。2.1 三种Bootloader配置的定位与选择根据NXP的官方资料Bootloader主要有三种交付和运行形态它们的区别远不止是“放在哪里”那么简单。1. ROM Bootloader这是由NXP在芯片出厂时预先固化在芯片内部ROM中的引导程序。对于开发者而言它是一个“黑盒”无法修改其源码。它的最大优势是“永远存在且可靠”即使外部Flash被意外擦除它依然能通过特定的串行接口如UART、USB、I2C等取决于具体芯片响应主机命令为恢复设备提供了最后一道保障。因此它最适合用于工厂批量编程和作为现场更新的最后救援手段。它的工作模式也很灵活既可以在系统启动时直接运行等待主机连接也可以被用户应用程序在运行时调用。2. Flash Loader这是我们本文的重点。它通常是由NXP预先编程到芯片Flash中的特定区域非用户程序区的二进制文件。与ROM Bootloader类似它也在系统启动时运行但其生命周期是“一次性”的——一旦用户程序被下载到Flash起始地址后续启动就会直接跳转到用户程序Flash Loader自身会被“覆盖”或不再执行。因此它主要定位于出厂前的工厂编程环节。对于KM35Z512这类没有内部ROM的芯片如果出厂时未预烧Flash Loader则需要开发者自行编译并烧录。3. Flash Bootloader (基于源码)这是NXP以源代码形式在MCUXpresso SDK中提供的完整Bootloader解决方案。开发者拥有最高的自由度可以对其进行深度定制例如裁剪不需要的通信接口、修改超时时间、增加安全校验等。它既可以配置为在系统启动时运行也可以被设计成由用户应用程序调用。因此它是实现灵活的现场更新FOTA功能的理想基础。我们需要下载、编译并烧录的正是这个版本的Bootloader。为了更清晰地对比我将三者的核心差异整理如下特性维度ROM BootloaderFlash LoaderFlash Bootloader (源码)交付形式芯片ROM预置二进制Flash预编程二进制MCU SDK中提供的源代码可定制性不可更改不可更改完全可配置、可修改主要用例工厂编程、救援更新工厂编程现场更新、定制化引导运行时机启动时或由应用调用始终在启动时运行启动时或由应用调用与用户程序关系超时后跳转至用户程序被用户程序覆盖超时后跳转至用户程序KM35Z512支持不支持无内部ROM出厂未预装需自行烧录支持需从SDK获取并编译注意对于KM35Z512项目由于芯片没有内置ROM且出厂Flash为空我们实际上是在利用Flash Bootloader的源码编译生成一个Flash Loader功能的二进制文件然后将其首次烧录到芯片中为后续的用户应用程序下载铺平道路。这个概念上的转换非常重要。2.2 MCU Flashloader的工作原理与流程理解其工作原理有助于我们在出现问题时进行排查。Flashloader本质上是一个存储在Flash中、但被加载到RAM中运行的小型程序。其工作流程可以概括为以下几个阶段上电/复位MCU复位后从默认的启动地址通常是Flash起始地址0x0000_0000开始执行指令。加载到RAM如果该地址存放的是我们编译好的Flashloader程序那么CPU将开始执行它。Flashloader代码的首要任务之一往往是将其自身或核心部分从相对较慢的Flash搬移到更快的RAM中以提升执行效率。外设初始化与监听Flashloader初始化其配置支持的通信接口例如UART。然后它会在该接口上监听来自主机工具如KinetisFlashTool或BLHOST的特定协议命令。协议交互主机工具通过发送符合MCU Bootloader标准协议的数据包与Flashloader通信。这个协议定义了诸如“获取属性”、“擦除内存”、“写入内存”、“执行程序”等一系列命令。执行命令Flashloader解析命令执行对应的操作。例如在收到“擦除-写入”命令序列后它会对内部Flash的指定区域进行擦除和编程。超时跳转或保持Flashloader通常会设置一个监听超时时间如几秒钟。如果在超时时间内未收到任何有效主机命令它会认为当前不需要编程于是直接跳转到指定的用户应用程序入口地址如0x0000_A000执行。如果收到命令则完成编程任务后根据主机命令决定是复位还是跳转。这个流程揭示了两个关键点一是通信协议是标准化的这也是BLHOST和KinetisFlashTool能通用不同型号Kinetis芯片的原因二是Flashloader的存放地址和用户程序的存放地址需要精心规划避免相互覆盖。3. 深入定制bootloader_config.h 文件解析拿到MCU-Boot的源代码后我们面对的第一个也是最重要的定制文件就是bootloader_config.h。这个头文件位于\middleware\mcu-boot\targets\MKM35Z512Z7\src\目录下它像是一个功能总开关面板决定了最终生成的Bootloader具备哪些能力。3.1 通信接口的配置与硬件适配Bootloader需要与外界通信而通信接口的选择必须与你的硬件设计严格匹配。配置错误将导致主机工具无法连接。// 示例在 bootloader_config.h 中启用 UART0 作为通信接口 #define BL_FEATURE_UART (1) // 启用UART接口支持 #define BL_UART_INTERFACE_TYPE (kUart) // 接口类型 #define BL_UART_PERIPHERAL (UART0) // 使用UART0外设 #define BL_UART_BAUDRATE (115200) // 默认波特率 #define BL_UART_CLOCK_FREQ (CLOCK_GetCoreSysClkFreq()) // UART时钟源频率关键配置项解析BL_FEATURE_UART 这是总开关设置为1才能编译进UART支持。BL_UART_PERIPHERAL 指定具体的UART实例如UART0,UART1,UART2等。这里必须与你的硬件原理图上MCU的UART引脚连接一致。例如如果你的调试串口连接的是MCU的UART0_RX/TX引脚这里就应配置为UART0。BL_UART_BAUDRATE 默认通信波特率。主机工具需要以此波特率进行连接。虽然部分Bootloader支持自动波特率检测通过BL_FEATURE_UART_AUTOBAUD_IRQ配置但设定一个合理的默认值如115200是良好实践。BL_UART_CLOCK_FREQ 这是最易出错的地方之一。它告诉Bootloader UART外设的输入时钟频率是多少用于精确计算波特率分频器。在KM35Z512上系统初始化后的核心时钟频率需要根据你的时钟树配置来确定。如果此值配置错误会导致实际波特率与设定值偏差巨大通信失败。一个稳妥的做法是在用户程序中先调试好时钟配置然后将确定的系统核心时钟频率值填在这里。实操心得在定制多接口支持时例如同时启用UART和USB务必注意引脚复用冲突。有些MCU的UART0和USB的DP/DM可能复用同一组引脚。在bootloader_config.h中你需要通过BL_ENABLE_PERIPH_PIN相关的宏来正确初始化引脚功能。我的建议是在Bootloader阶段尽量保持硬件设计简单优先使用一个经过充分验证的接口如UART避免不必要的复杂度。3.2 核心功能特性的使能与优化除了通信接口bootloader_config.h中还有一系列功能特性宏它们决定了Bootloader的行为和健壮性。表关键功能配置选项详解配置宏推荐值功能描述与配置解析BL_FEATURE_CRC_CHECK1 (强烈建议启用)CRC校验使能。启用后Bootloader会对接收到的每一个命令或数据包进行CRC校验。这是保证数据传输可靠性的关键防线能有效避免因噪声干扰导致的Flash错误编程。务必启用。BL_FEATURE_FILL_MEMORY1 (必须启用)内存编程使能。这个功能是Bootloader的核心允许主机向指定地址写入数据。如果禁用Bootloader将失去编程Flash的能力仅能用于读取或擦除。对于下载应用程序的场景此选项必须为1。BL_FEATURE_READ_MEMORY0 或 1内存读取使能。允许主机从设备读取内存内容。对于仅需要下载功能的量产场景可以关闭(0)以略微减小代码体积。对于调试和验证阶段建议开启(1)方便读取Flash内容进行确认。BL_FEATURE_QSPI_MODULE0 (对于KM35Z512)QSPI外置Flash支持。KM35Z512主要管理内部Flash通常不涉及QSPI接口的外部存储器启动。除非你的硬件设计特殊否则设为0。BL_FEATURE_ENCRYPTION0 (对于基础应用)加密支持。启用此功能可以支持对传输的数据进行加密提高固件升级的安全性。但这会增加代码复杂性和大小。在初期开发和不需要安全升级的场景下设为0即可。BL_FEATURE_UART_AUTOBAUD_IRQ1UART自动波特率检测。这是一个非常实用的功能。启用后Bootloader可以通过检测主机发送的特定同步字符如0x5A自动校准波特率无需主机与Bootloader的波特率严格匹配。强烈建议启用它能极大简化主机连接时的配置。配置技巧在资源紧张的MCU上我们需要权衡功能与代码大小。一个最小化的、仅用于工厂烧录的Bootloader可以只保留BL_FEATURE_FILL_MEMORY和BL_FEATURE_CRC_CHECK并关闭其他所有非必需功能如读取、加密、其他接口等。你可以通过编译后查看生成的.map文件或二进制文件大小来评估裁剪效果。4. 实战演练从获取SDK到烧录演示程序理论说得再多不如动手操作一遍。我们以NXP TWR-KM35Z512开发板为例完成一次完整的Flashloader编译、下载和应用演示。4.1 获取MCUXpresso SDK与MCU-Boot中间件NXP已将MCU-Boot作为中间件集成到了MCUXpresso SDK中这是获取源码最官方、最便捷的途径。访问SDK构建器 打开 MCUXpresso SDK Builder 网站。你需要一个NXP账号免费注册来登录。选择开发板 点击“Select Board”在搜索框中输入“KM35Z512”。从结果中选择“TWR-KM35Z512Z75M”。这一步至关重要因为它确保了后续下载的SDK包含了针对该板卡的所有外设驱动、引脚配置和示例工程。定制SDK组件 在“Build SDK”页面你会看到所有可选的中间件和组件。找到“mcu-boot”并勾选它。这里你也可以根据需求勾选其他组件但为了减小首次下载的SDK体积可以只选mcu-boot。下载SDK 点击页面底部的“Download SDK”。等待服务器生成后下载得到一个压缩包如SDK_2.7.1_TWR-KM35Z75M.tar.gz。解压后你就得到了一个包含MCU-Boot完整源码、主机工具和示例工程的本地SDK目录。注意SDK版本号如2.7.1可能会更新请以官网最新版本为准。不同版本的SDK目录结构可能略有差异但核心路径通常保持一致。4.2 编译Bootloader与演示应用程序SDK中已经为我们准备好了针对TWR-KM35Z512开发板的示例工程我们需要用IDE如MCUXpresso IDE, IAR, Keil MDK打开并编译它们。1. 定位示例工程解压后的SDK目录结构清晰相关资源位置如下表所示资源名称在SDK中的典型路径说明Bootloader示例工程\boards\twrKM35Z512z75m\bootloader_examples\tower_bootloader用于生成Flashloader二进制文件的IAR/Keil/MCUXpresso工程。演示应用程序\boards\twrKM35Z512z75m\bootloader_examples\demo_apps\led_demo_tower_a000一个简单的LED闪烁程序编译后地址在0xA000用于测试Bootloader。MCU-Boot源码\middleware\mcu-bootBootloader的核心实现源码我们之前配置的bootloader_config.h就在其子目录下。主机工具 (BLHOST)\middleware\mcu-boot\bin\Tools\blhost\命令行工具支持Windows(.exe)、Linux(.)。主机工具 (GUI)\middleware\mcu-boot\bin\Tools\KinetisFlashTool\图形化工具KinetisFlashTool.exe。2. 编译Bootloader工程使用你熟悉的IDE打开tower_bootloader工程。确保工程配置中的链接地址Link Address正确。对于Flashloader它通常被链接到Flash的起始地址如0x0000_0000。这一点在工程配置的链接器脚本.ld文件中已经设置好一般无需修改但务必确认。编译工程。成功后在输出目录如Debug会生成一个.bin或.hex或.s19文件。我们最终需要的是二进制.bin文件因为它不包含地址信息方便主机工具直接写入指定地址。大多数IDE在编译后会同时生成多种格式也可以使用arm-none-eabi-objcopy工具从.elf文件转换得到.bin文件。3. 编译演示应用程序打开led_demo_tower_a000工程。关键步骤检查并修改链接地址。这个演示程序之所以叫a000是因为它的链接地址被设置为0x0000_A000。这是为了给从0x0000_0000开始的Bootloader预留空间。你必须确认工程的链接器脚本或分散加载文件正确地将.text、.data等段定位在0xA000之后。这是Bootloader能否成功跳转的关键。编译该工程并同样生成其.bin文件。为了方便后续操作我将这个led_demo_tower_a000.bin文件复制到了blhost工具所在的目录例如...\blhost\win\。避坑经验第一次编译Bootloader工程时很可能会遇到大量头文件找不到的错误。这通常是因为工程没有正确包含MCUXpresso SDK的根目录路径。你需要在IDE的工程属性中将SDK的根目录即包含devices,components,middleware等文件夹的目录添加到“包含路径Include Paths”或“全局宏Global Macros”中。MCUXpresso IDE新建的工程通常会自动处理好这些依赖但使用Keil或IAR导入时可能需要手动配置。4.3 使用KinetisFlashToolGUI下载程序对于不熟悉命令行的开发者或者希望快速进行原型验证图形化的KinetisFlashTool是首选。硬件连接与上电 使用USB线将TWR-KM35Z512开发板的OpenSDA调试口连接到电脑。电脑会识别出一个虚拟串口COM口例如COM12。确保开发板供电正常。运行工具并连接 打开KinetisFlashTool.exe。在界面中选择通信接口为“UART”。在“Port”下拉菜单中选择正确的COM口。波特率选择“115200”与bootloader_config.h中的默认设置一致。点击“Connect”按钮。触发Bootloader在点击“Connect”的同时或之前按下开发板上的复位Reset按钮。这个时机很重要目的是让MCU复位后立即运行Flashloader并进入等待命令的状态。如果连接成功下方的状态栏会显示目标设备的信息如Flash起始地址、大小等。下载应用程序在“Image”区域点击“Browse”选择我们编译好的led_demo_tower_a000.bin文件。在“Target Address”中输入0x0000_A000。这个地址必须与应用程序的链接地址完全一致。点击“Update”按钮。工具会依次执行擦除、编程、校验等操作。验证与跳转 编程完成后再次按下复位键。此时Flashloader会启动由于没有收到主机命令超时它会自动跳转到0xA000地址执行。你应该能看到开发板上的用户LED开始闪烁这表明Bootloader成功加载并运行了用户程序。提示如果连接失败请按以下顺序排查① 确认COM口选择正确② 确认波特率设置正确③ 确保在点击连接时复位了MCU④ 检查Bootloader程序是否已成功烧录到板子的Flash起始位置可能需要先用J-Link等调试器烧录一次Bootloader的.bin文件到0x00000000。4.4 使用BLHOSTCLI进行高级操作与自动化命令行工具BLHOST虽然不如GUI直观但它功能更强大且易于集成到自动化脚本或持续集成CI流程中。以下是在Windows命令提示符CMD或PowerShell中的操作步骤假设blhost.exe和led_demo_tower_a000.bin都在当前目录。步骤1建立连接与获取信息# 语法blhost -p COM端口,波特率 命令 [参数] # 示例ping设备并获取属性 blhost -p COM12,115200 get-property 1-p COM12,115200: 指定串口和波特率。get-property 1: 命令1代表“获取属性”这里用于获取Bootloader版本等信息也常作为“ping”操作来测试连接。执行时机同样需要在MCU复位后立即运行此命令。你可以先输入命令回车前按下复位键然后迅速回车发送。如果连接成功你会看到类似以下的反馈其中包含了Bootloader版本号Response status 0 (0x0) Success. Response word 1 0x1060000 (2.16.0)步骤2擦除目标Flash区域在写入新程序前必须擦除对应的Flash扇区。# 语法flash-erase-region 起始地址 大小字节 # 示例擦除以0xA000开始大小为0xA000即40KB的区域 blhost -p COM12,115200 flash-erase-region 0xA000 0xA000擦除大小必须是Flash扇区大小的整数倍。对于KM35Z512你需要查阅数据手册来确定扇区大小例如可能是2KB或4KB。这里擦除0xA00040KB是一个示例确保覆盖了整个演示程序占用的空间。步骤3写入应用程序二进制文件# 语法write-memory 起始地址 文件名.bin # 示例将led_demo_tower_a000.bin写入0xA000地址 blhost -p COM12,115200 write-memory 0xA000 led_demo_tower_a000.bin这个命令会将二进制文件的内容逐段写入指定的Flash地址。BLHOST内部会处理数据分包和协议通信。步骤4跳转到应用程序执行# 语法execute 地址 参数1 参数2 # 示例跳转到0xA000地址执行参数传递0 blhost -p COM12,115200 execute 0xA000 0 0执行此命令后Bootloader会直接跳转到0xA000地址并将两个参数此处均为0传递给应用程序。此时LED应该开始闪烁。自动化脚本思路你可以将上述命令写入一个批处理文件.bat或Shell脚本中实现一键烧录。这对于量产测试或频繁的固件验证非常有用。echo off echo 正在连接Bootloader... blhost -p COM12,115200 get-property 1 if errorlevel 1 ( echo 连接失败请检查硬件和端口 pause exit /b 1 ) echo 擦除Flash区域... blhost -p COM12,115200 flash-erase-region 0xA000 0xA000 echo 写入应用程序... blhost -p COM12,115200 write-memory 0xA000 my_application.bin echo 跳转执行... blhost -p COM12,115200 execute 0xA000 0 0 echo 所有操作完成 pause5. 开发与调试中的常见问题与解决方案在实际项目中使用Flashloader很少一帆风顺。下面我整理了几个最常见的问题及其排查思路希望能帮你节省大量调试时间。5.1 连接失败主机工具无法与Bootloader通信这是最令人头疼的问题。请按照以下清单逐步排查硬件连接线缆 确认使用的是数据线而非仅充电线。端口 在设备管理器中确认虚拟COM口编号并确保没有被其他软件如串口助手、IDE占用。电平 确保主机通常是PC的USB转串口与MCU的UART电平匹配通常是3.3V TTL。TWR开发板的OpenSDA电路已处理好这一点但如果是自定义板卡务必检查电平转换电路。Bootloader配置与烧录Bootloader是否存在 这是首要问题。你的MCU Flash起始地址0x0000_0000是否已经正确烧录了编译好的Bootloader二进制文件第一次必须使用JTAG/SWD调试器如J-Link、OpenSDA将Bootloader.bin烧录到0x0地址。之后才能通过UART更新。接口配置 反复核对bootloader_config.h中的BL_UART_PERIPHERAL和BL_UART_BAUDRATE是否与硬件设计一致。时钟配置BL_UART_CLOCK_FREQ是否正确一个错误的时钟频率会导致波特率生成错误。建议在用户程序中先调试好UART通信确认时钟配置再将这个频率值用于Bootloader配置。操作时序复位时机 Bootloader通常只在复位后的一个很短的时间窗口内如1-3秒监听主机。必须在点击“连接”或发送第一条命令的同时或之后极短时间内按下复位键。可以尝试编写脚本在发送命令前自动触发DTR/RTS信号来复位MCU如果硬件支持。工具与驱动驱动 确保OpenSDA或FTDI等USB转串口芯片的驱动已正确安装。工具版本 尝试使用SDK中自带的blhost和KinetisFlashTool确保其与Bootloader的协议版本兼容。5.2 应用程序无法运行Bootloader跳转后无反应Bootloader能连接并下载程序但复位后应用程序不执行。链接地址冲突这是最常见的原因。确保你的应用程序的链接地址尤其是向量表起始地址与Bootloader中配置的跳转地址一致并且没有覆盖Bootloader自身的代码区域。对于从0xA000开始的应用程序其向量表也必须位于0xA000。在IDE的链接器设置中仔细检查。向量表重映射 对于Cortex-M内核中断向量表的第一个字是初始栈指针MSP第二个字是复位向量程序入口。Bootloader跳转时需要将MCU的VTOR向量表偏移寄存器设置为应用程序的向量表地址。检查Bootloader的跳转代码通常是bl_user_entry()或类似函数是否正确地设置了VTOR。在MCU-Boot源码中这个操作通常是自动完成的但如果你做了深度定制需要确认。时钟与外设初始化 Bootloader可能已经初始化了系统时钟和一些外设如UART。跳转到应用程序后应用程序不应假设所有外设都处于复位状态。一个稳健的做法是在应用程序的main()函数最开始重新初始化所有你需要用到的核心外设至少是系统时钟。看门狗Watchdog 检查Bootloader是否使能了看门狗且未喂狗。如果Bootloader使能了看门狗并在跳转前没有禁用它应用程序必须在超时前及时喂狗否则会导致不断复位。5.3 数据校验失败CRC错误或编程验证失败在使用write-memory命令时可能会报告CRC校验失败或编程验证错误。电气干扰 长距离、无屏蔽的串口连接容易引入噪声导致数据错误。确保通信环境良好线缆质量过关。启用BL_FEATURE_CRC_CHECK正是为了应对这种情况。波特率过高 在长线或干扰环境下过高的波特率如921600可能不稳定。尝试降低波特率到115200甚至9600。Flash编程算法 Bootloader内部的Flash驱动驱动层可能有问题。确认bootloader_config.h中关于Flash驱动的配置如BL_FEATURE_FLASH_SECURITY等与你的芯片型号匹配。可以尝试用调试器直接通过JTAG接口编程同一个二进制文件如果成功则问题很可能在Bootloader的Flash驱动部分。内存范围 确保你擦除和编程的地址范围是有效的用户Flash区域没有触及受保护的区域如Flash配置字段或根本不存在的地址。5.4 如何更新已部署产品的固件现场升级这是Bootloader的终极价值所在。你需要设计一个完整的现场更新机制应用程序中的Bootloader调用 在你的用户应用程序中预留一个入口如通过特定串口命令、按键组合或网络指令来调用Bootloader。MCU-Boot源码通常提供一个bl_user_entry()之类的API你可以在应用程序中直接调用它从而重新进入Bootloader模式等待主机连接升级而无需物理复位。双映像Dual Image与回滚 为了升级安全高级的Bootloader会支持A/B分区。当下载新固件到B分区后进行校验校验成功后再将启动标志切换到B分区。如果新固件启动失败可以自动回滚到A分区。这需要在Bootloader中实现更复杂的逻辑并规划好Flash分区。通信协议与安全 对于通过公共网络如4G、Wi-Fi进行的无线升级FOTA必须在应用层设计可靠的传输协议如分段、校验、重传并强烈建议引入加密和签名验证防止固件被篡改。从理解Bootloader的三种形态到深入bootloader_config.h进行精准定制再到亲手编译、烧录并通过两种工具完成更新我们走完了Kinetis Flashloader从概念到实践的全过程。其中最关键的是地址规划和配置匹配——你的应用程序链接地址、Bootloader的跳转地址、主机工具的写入地址这三者必须构成一个自洽的链条。而调试的起点永远是确认最基本的硬件连接和Bootloader程序本身是否已就位。在实际产品开发中我倾向于将Bootloader做得尽可能精简和稳定只保留最必要的UART接口和编程功能。对于现场升级则会设计一个更复杂的、位于应用程序内部的升级代理由它来负责新固件的下载、校验和切换Bootloader只作为最后一步的“编程执行者”。这样既能降低Bootloader的复杂度又能提高升级流程的灵活性和可靠性。希望这些经验能帮助你更好地将Flashloader集成到自己的项目中让固件更新不再是难题。
Kinetis MCU Flashloader配置与实战：从源码编译到固件更新全解析
发布时间：2026/6/8 22:53:16
1. 项目概述与核心价值在嵌入式开发领域尤其是基于NXP Kinetis系列MCU的项目中如何高效、可靠地完成固件更新是每个工程师都会面临的挑战。无论是产品出厂前的批量烧录还是产品部署到现场后的远程升级一个稳定、灵活的Bootloader引导加载程序都是不可或缺的基石。今天我想和大家深入聊聊Kinetis MCU的Flashloader这不仅仅是一个“烧录工具”更是一个连接开发环境与最终硬件产品的桥梁。Flashloader是MCU Bootloader的一种具体实现它的核心价值在于允许我们将一个可执行的引导程序加载到MCU的RAM中运行。这种设计巧妙地将用户应用程序固定在Flash存储器的起始地址实现上电自动启动而Bootloader本身则作为“一次性编程助手”在需要更新固件时才被激活。对于像KM35Z512这类内部没有ROM Bootloader的芯片由NXP提供的Flash Bootloader源码就显得尤为重要它赋予了开发者从零构建定制化引导流程的能力。本文将从一个实践者的角度拆解Flashloader的配置、编译、使用全流程并分享我在实际项目中积累的一些关键技巧和避坑经验希望能帮助大家更顺畅地驾驭这项技术。2. Kinetis Bootloader体系深度解析在动手配置之前我们必须先理解NXP为Kinetis MCU提供的Bootloader“全家桶”。不同的配置对应着不同的应用场景和硬件限制选型错误可能会导致后续开发事倍功半。2.1 三种Bootloader配置的定位与选择根据NXP的官方资料Bootloader主要有三种交付和运行形态它们的区别远不止是“放在哪里”那么简单。1. ROM Bootloader这是由NXP在芯片出厂时预先固化在芯片内部ROM中的引导程序。对于开发者而言它是一个“黑盒”无法修改其源码。它的最大优势是“永远存在且可靠”即使外部Flash被意外擦除它依然能通过特定的串行接口如UART、USB、I2C等取决于具体芯片响应主机命令为恢复设备提供了最后一道保障。因此它最适合用于工厂批量编程和作为现场更新的最后救援手段。它的工作模式也很灵活既可以在系统启动时直接运行等待主机连接也可以被用户应用程序在运行时调用。2. Flash Loader这是我们本文的重点。它通常是由NXP预先编程到芯片Flash中的特定区域非用户程序区的二进制文件。与ROM Bootloader类似它也在系统启动时运行但其生命周期是“一次性”的——一旦用户程序被下载到Flash起始地址后续启动就会直接跳转到用户程序Flash Loader自身会被“覆盖”或不再执行。因此它主要定位于出厂前的工厂编程环节。对于KM35Z512这类没有内部ROM的芯片如果出厂时未预烧Flash Loader则需要开发者自行编译并烧录。3. Flash Bootloader (基于源码)这是NXP以源代码形式在MCUXpresso SDK中提供的完整Bootloader解决方案。开发者拥有最高的自由度可以对其进行深度定制例如裁剪不需要的通信接口、修改超时时间、增加安全校验等。它既可以配置为在系统启动时运行也可以被设计成由用户应用程序调用。因此它是实现灵活的现场更新FOTA功能的理想基础。我们需要下载、编译并烧录的正是这个版本的Bootloader。为了更清晰地对比我将三者的核心差异整理如下特性维度ROM BootloaderFlash LoaderFlash Bootloader (源码)交付形式芯片ROM预置二进制Flash预编程二进制MCU SDK中提供的源代码可定制性不可更改不可更改完全可配置、可修改主要用例工厂编程、救援更新工厂编程现场更新、定制化引导运行时机启动时或由应用调用始终在启动时运行启动时或由应用调用与用户程序关系超时后跳转至用户程序被用户程序覆盖超时后跳转至用户程序KM35Z512支持不支持无内部ROM出厂未预装需自行烧录支持需从SDK获取并编译注意对于KM35Z512项目由于芯片没有内置ROM且出厂Flash为空我们实际上是在利用Flash Bootloader的源码编译生成一个Flash Loader功能的二进制文件然后将其首次烧录到芯片中为后续的用户应用程序下载铺平道路。这个概念上的转换非常重要。2.2 MCU Flashloader的工作原理与流程理解其工作原理有助于我们在出现问题时进行排查。Flashloader本质上是一个存储在Flash中、但被加载到RAM中运行的小型程序。其工作流程可以概括为以下几个阶段上电/复位MCU复位后从默认的启动地址通常是Flash起始地址0x0000_0000开始执行指令。加载到RAM如果该地址存放的是我们编译好的Flashloader程序那么CPU将开始执行它。Flashloader代码的首要任务之一往往是将其自身或核心部分从相对较慢的Flash搬移到更快的RAM中以提升执行效率。外设初始化与监听Flashloader初始化其配置支持的通信接口例如UART。然后它会在该接口上监听来自主机工具如KinetisFlashTool或BLHOST的特定协议命令。协议交互主机工具通过发送符合MCU Bootloader标准协议的数据包与Flashloader通信。这个协议定义了诸如“获取属性”、“擦除内存”、“写入内存”、“执行程序”等一系列命令。执行命令Flashloader解析命令执行对应的操作。例如在收到“擦除-写入”命令序列后它会对内部Flash的指定区域进行擦除和编程。超时跳转或保持Flashloader通常会设置一个监听超时时间如几秒钟。如果在超时时间内未收到任何有效主机命令它会认为当前不需要编程于是直接跳转到指定的用户应用程序入口地址如0x0000_A000执行。如果收到命令则完成编程任务后根据主机命令决定是复位还是跳转。这个流程揭示了两个关键点一是通信协议是标准化的这也是BLHOST和KinetisFlashTool能通用不同型号Kinetis芯片的原因二是Flashloader的存放地址和用户程序的存放地址需要精心规划避免相互覆盖。3. 深入定制bootloader_config.h 文件解析拿到MCU-Boot的源代码后我们面对的第一个也是最重要的定制文件就是bootloader_config.h。这个头文件位于\middleware\mcu-boot\targets\MKM35Z512Z7\src\目录下它像是一个功能总开关面板决定了最终生成的Bootloader具备哪些能力。3.1 通信接口的配置与硬件适配Bootloader需要与外界通信而通信接口的选择必须与你的硬件设计严格匹配。配置错误将导致主机工具无法连接。// 示例在 bootloader_config.h 中启用 UART0 作为通信接口 #define BL_FEATURE_UART (1) // 启用UART接口支持 #define BL_UART_INTERFACE_TYPE (kUart) // 接口类型 #define BL_UART_PERIPHERAL (UART0) // 使用UART0外设 #define BL_UART_BAUDRATE (115200) // 默认波特率 #define BL_UART_CLOCK_FREQ (CLOCK_GetCoreSysClkFreq()) // UART时钟源频率关键配置项解析BL_FEATURE_UART 这是总开关设置为1才能编译进UART支持。BL_UART_PERIPHERAL 指定具体的UART实例如UART0,UART1,UART2等。这里必须与你的硬件原理图上MCU的UART引脚连接一致。例如如果你的调试串口连接的是MCU的UART0_RX/TX引脚这里就应配置为UART0。BL_UART_BAUDRATE 默认通信波特率。主机工具需要以此波特率进行连接。虽然部分Bootloader支持自动波特率检测通过BL_FEATURE_UART_AUTOBAUD_IRQ配置但设定一个合理的默认值如115200是良好实践。BL_UART_CLOCK_FREQ 这是最易出错的地方之一。它告诉Bootloader UART外设的输入时钟频率是多少用于精确计算波特率分频器。在KM35Z512上系统初始化后的核心时钟频率需要根据你的时钟树配置来确定。如果此值配置错误会导致实际波特率与设定值偏差巨大通信失败。一个稳妥的做法是在用户程序中先调试好时钟配置然后将确定的系统核心时钟频率值填在这里。实操心得在定制多接口支持时例如同时启用UART和USB务必注意引脚复用冲突。有些MCU的UART0和USB的DP/DM可能复用同一组引脚。在bootloader_config.h中你需要通过BL_ENABLE_PERIPH_PIN相关的宏来正确初始化引脚功能。我的建议是在Bootloader阶段尽量保持硬件设计简单优先使用一个经过充分验证的接口如UART避免不必要的复杂度。3.2 核心功能特性的使能与优化除了通信接口bootloader_config.h中还有一系列功能特性宏它们决定了Bootloader的行为和健壮性。表关键功能配置选项详解配置宏推荐值功能描述与配置解析BL_FEATURE_CRC_CHECK1 (强烈建议启用)CRC校验使能。启用后Bootloader会对接收到的每一个命令或数据包进行CRC校验。这是保证数据传输可靠性的关键防线能有效避免因噪声干扰导致的Flash错误编程。务必启用。BL_FEATURE_FILL_MEMORY1 (必须启用)内存编程使能。这个功能是Bootloader的核心允许主机向指定地址写入数据。如果禁用Bootloader将失去编程Flash的能力仅能用于读取或擦除。对于下载应用程序的场景此选项必须为1。BL_FEATURE_READ_MEMORY0 或 1内存读取使能。允许主机从设备读取内存内容。对于仅需要下载功能的量产场景可以关闭(0)以略微减小代码体积。对于调试和验证阶段建议开启(1)方便读取Flash内容进行确认。BL_FEATURE_QSPI_MODULE0 (对于KM35Z512)QSPI外置Flash支持。KM35Z512主要管理内部Flash通常不涉及QSPI接口的外部存储器启动。除非你的硬件设计特殊否则设为0。BL_FEATURE_ENCRYPTION0 (对于基础应用)加密支持。启用此功能可以支持对传输的数据进行加密提高固件升级的安全性。但这会增加代码复杂性和大小。在初期开发和不需要安全升级的场景下设为0即可。BL_FEATURE_UART_AUTOBAUD_IRQ1UART自动波特率检测。这是一个非常实用的功能。启用后Bootloader可以通过检测主机发送的特定同步字符如0x5A自动校准波特率无需主机与Bootloader的波特率严格匹配。强烈建议启用它能极大简化主机连接时的配置。配置技巧在资源紧张的MCU上我们需要权衡功能与代码大小。一个最小化的、仅用于工厂烧录的Bootloader可以只保留BL_FEATURE_FILL_MEMORY和BL_FEATURE_CRC_CHECK并关闭其他所有非必需功能如读取、加密、其他接口等。你可以通过编译后查看生成的.map文件或二进制文件大小来评估裁剪效果。4. 实战演练从获取SDK到烧录演示程序理论说得再多不如动手操作一遍。我们以NXP TWR-KM35Z512开发板为例完成一次完整的Flashloader编译、下载和应用演示。4.1 获取MCUXpresso SDK与MCU-Boot中间件NXP已将MCU-Boot作为中间件集成到了MCUXpresso SDK中这是获取源码最官方、最便捷的途径。访问SDK构建器 打开 MCUXpresso SDK Builder 网站。你需要一个NXP账号免费注册来登录。选择开发板 点击“Select Board”在搜索框中输入“KM35Z512”。从结果中选择“TWR-KM35Z512Z75M”。这一步至关重要因为它确保了后续下载的SDK包含了针对该板卡的所有外设驱动、引脚配置和示例工程。定制SDK组件 在“Build SDK”页面你会看到所有可选的中间件和组件。找到“mcu-boot”并勾选它。这里你也可以根据需求勾选其他组件但为了减小首次下载的SDK体积可以只选mcu-boot。下载SDK 点击页面底部的“Download SDK”。等待服务器生成后下载得到一个压缩包如SDK_2.7.1_TWR-KM35Z75M.tar.gz。解压后你就得到了一个包含MCU-Boot完整源码、主机工具和示例工程的本地SDK目录。注意SDK版本号如2.7.1可能会更新请以官网最新版本为准。不同版本的SDK目录结构可能略有差异但核心路径通常保持一致。4.2 编译Bootloader与演示应用程序SDK中已经为我们准备好了针对TWR-KM35Z512开发板的示例工程我们需要用IDE如MCUXpresso IDE, IAR, Keil MDK打开并编译它们。1. 定位示例工程解压后的SDK目录结构清晰相关资源位置如下表所示资源名称在SDK中的典型路径说明Bootloader示例工程\boards\twrKM35Z512z75m\bootloader_examples\tower_bootloader用于生成Flashloader二进制文件的IAR/Keil/MCUXpresso工程。演示应用程序\boards\twrKM35Z512z75m\bootloader_examples\demo_apps\led_demo_tower_a000一个简单的LED闪烁程序编译后地址在0xA000用于测试Bootloader。MCU-Boot源码\middleware\mcu-bootBootloader的核心实现源码我们之前配置的bootloader_config.h就在其子目录下。主机工具 (BLHOST)\middleware\mcu-boot\bin\Tools\blhost\命令行工具支持Windows(.exe)、Linux(.)。主机工具 (GUI)\middleware\mcu-boot\bin\Tools\KinetisFlashTool\图形化工具KinetisFlashTool.exe。2. 编译Bootloader工程使用你熟悉的IDE打开tower_bootloader工程。确保工程配置中的链接地址Link Address正确。对于Flashloader它通常被链接到Flash的起始地址如0x0000_0000。这一点在工程配置的链接器脚本.ld文件中已经设置好一般无需修改但务必确认。编译工程。成功后在输出目录如Debug会生成一个.bin或.hex或.s19文件。我们最终需要的是二进制.bin文件因为它不包含地址信息方便主机工具直接写入指定地址。大多数IDE在编译后会同时生成多种格式也可以使用arm-none-eabi-objcopy工具从.elf文件转换得到.bin文件。3. 编译演示应用程序打开led_demo_tower_a000工程。关键步骤检查并修改链接地址。这个演示程序之所以叫a000是因为它的链接地址被设置为0x0000_A000。这是为了给从0x0000_0000开始的Bootloader预留空间。你必须确认工程的链接器脚本或分散加载文件正确地将.text、.data等段定位在0xA000之后。这是Bootloader能否成功跳转的关键。编译该工程并同样生成其.bin文件。为了方便后续操作我将这个led_demo_tower_a000.bin文件复制到了blhost工具所在的目录例如...\blhost\win\。避坑经验第一次编译Bootloader工程时很可能会遇到大量头文件找不到的错误。这通常是因为工程没有正确包含MCUXpresso SDK的根目录路径。你需要在IDE的工程属性中将SDK的根目录即包含devices,components,middleware等文件夹的目录添加到“包含路径Include Paths”或“全局宏Global Macros”中。MCUXpresso IDE新建的工程通常会自动处理好这些依赖但使用Keil或IAR导入时可能需要手动配置。4.3 使用KinetisFlashToolGUI下载程序对于不熟悉命令行的开发者或者希望快速进行原型验证图形化的KinetisFlashTool是首选。硬件连接与上电 使用USB线将TWR-KM35Z512开发板的OpenSDA调试口连接到电脑。电脑会识别出一个虚拟串口COM口例如COM12。确保开发板供电正常。运行工具并连接 打开KinetisFlashTool.exe。在界面中选择通信接口为“UART”。在“Port”下拉菜单中选择正确的COM口。波特率选择“115200”与bootloader_config.h中的默认设置一致。点击“Connect”按钮。触发Bootloader在点击“Connect”的同时或之前按下开发板上的复位Reset按钮。这个时机很重要目的是让MCU复位后立即运行Flashloader并进入等待命令的状态。如果连接成功下方的状态栏会显示目标设备的信息如Flash起始地址、大小等。下载应用程序在“Image”区域点击“Browse”选择我们编译好的led_demo_tower_a000.bin文件。在“Target Address”中输入0x0000_A000。这个地址必须与应用程序的链接地址完全一致。点击“Update”按钮。工具会依次执行擦除、编程、校验等操作。验证与跳转 编程完成后再次按下复位键。此时Flashloader会启动由于没有收到主机命令超时它会自动跳转到0xA000地址执行。你应该能看到开发板上的用户LED开始闪烁这表明Bootloader成功加载并运行了用户程序。提示如果连接失败请按以下顺序排查① 确认COM口选择正确② 确认波特率设置正确③ 确保在点击连接时复位了MCU④ 检查Bootloader程序是否已成功烧录到板子的Flash起始位置可能需要先用J-Link等调试器烧录一次Bootloader的.bin文件到0x00000000。4.4 使用BLHOSTCLI进行高级操作与自动化命令行工具BLHOST虽然不如GUI直观但它功能更强大且易于集成到自动化脚本或持续集成CI流程中。以下是在Windows命令提示符CMD或PowerShell中的操作步骤假设blhost.exe和led_demo_tower_a000.bin都在当前目录。步骤1建立连接与获取信息# 语法blhost -p COM端口,波特率 命令 [参数] # 示例ping设备并获取属性 blhost -p COM12,115200 get-property 1-p COM12,115200: 指定串口和波特率。get-property 1: 命令1代表“获取属性”这里用于获取Bootloader版本等信息也常作为“ping”操作来测试连接。执行时机同样需要在MCU复位后立即运行此命令。你可以先输入命令回车前按下复位键然后迅速回车发送。如果连接成功你会看到类似以下的反馈其中包含了Bootloader版本号Response status 0 (0x0) Success. Response word 1 0x1060000 (2.16.0)步骤2擦除目标Flash区域在写入新程序前必须擦除对应的Flash扇区。# 语法flash-erase-region 起始地址 大小字节 # 示例擦除以0xA000开始大小为0xA000即40KB的区域 blhost -p COM12,115200 flash-erase-region 0xA000 0xA000擦除大小必须是Flash扇区大小的整数倍。对于KM35Z512你需要查阅数据手册来确定扇区大小例如可能是2KB或4KB。这里擦除0xA00040KB是一个示例确保覆盖了整个演示程序占用的空间。步骤3写入应用程序二进制文件# 语法write-memory 起始地址 文件名.bin # 示例将led_demo_tower_a000.bin写入0xA000地址 blhost -p COM12,115200 write-memory 0xA000 led_demo_tower_a000.bin这个命令会将二进制文件的内容逐段写入指定的Flash地址。BLHOST内部会处理数据分包和协议通信。步骤4跳转到应用程序执行# 语法execute 地址 参数1 参数2 # 示例跳转到0xA000地址执行参数传递0 blhost -p COM12,115200 execute 0xA000 0 0执行此命令后Bootloader会直接跳转到0xA000地址并将两个参数此处均为0传递给应用程序。此时LED应该开始闪烁。自动化脚本思路你可以将上述命令写入一个批处理文件.bat或Shell脚本中实现一键烧录。这对于量产测试或频繁的固件验证非常有用。echo off echo 正在连接Bootloader... blhost -p COM12,115200 get-property 1 if errorlevel 1 ( echo 连接失败请检查硬件和端口 pause exit /b 1 ) echo 擦除Flash区域... blhost -p COM12,115200 flash-erase-region 0xA000 0xA000 echo 写入应用程序... blhost -p COM12,115200 write-memory 0xA000 my_application.bin echo 跳转执行... blhost -p COM12,115200 execute 0xA000 0 0 echo 所有操作完成 pause5. 开发与调试中的常见问题与解决方案在实际项目中使用Flashloader很少一帆风顺。下面我整理了几个最常见的问题及其排查思路希望能帮你节省大量调试时间。5.1 连接失败主机工具无法与Bootloader通信这是最令人头疼的问题。请按照以下清单逐步排查硬件连接线缆 确认使用的是数据线而非仅充电线。端口 在设备管理器中确认虚拟COM口编号并确保没有被其他软件如串口助手、IDE占用。电平 确保主机通常是PC的USB转串口与MCU的UART电平匹配通常是3.3V TTL。TWR开发板的OpenSDA电路已处理好这一点但如果是自定义板卡务必检查电平转换电路。Bootloader配置与烧录Bootloader是否存在 这是首要问题。你的MCU Flash起始地址0x0000_0000是否已经正确烧录了编译好的Bootloader二进制文件第一次必须使用JTAG/SWD调试器如J-Link、OpenSDA将Bootloader.bin烧录到0x0地址。之后才能通过UART更新。接口配置 反复核对bootloader_config.h中的BL_UART_PERIPHERAL和BL_UART_BAUDRATE是否与硬件设计一致。时钟配置BL_UART_CLOCK_FREQ是否正确一个错误的时钟频率会导致波特率生成错误。建议在用户程序中先调试好UART通信确认时钟配置再将这个频率值用于Bootloader配置。操作时序复位时机 Bootloader通常只在复位后的一个很短的时间窗口内如1-3秒监听主机。必须在点击“连接”或发送第一条命令的同时或之后极短时间内按下复位键。可以尝试编写脚本在发送命令前自动触发DTR/RTS信号来复位MCU如果硬件支持。工具与驱动驱动 确保OpenSDA或FTDI等USB转串口芯片的驱动已正确安装。工具版本 尝试使用SDK中自带的blhost和KinetisFlashTool确保其与Bootloader的协议版本兼容。5.2 应用程序无法运行Bootloader跳转后无反应Bootloader能连接并下载程序但复位后应用程序不执行。链接地址冲突这是最常见的原因。确保你的应用程序的链接地址尤其是向量表起始地址与Bootloader中配置的跳转地址一致并且没有覆盖Bootloader自身的代码区域。对于从0xA000开始的应用程序其向量表也必须位于0xA000。在IDE的链接器设置中仔细检查。向量表重映射 对于Cortex-M内核中断向量表的第一个字是初始栈指针MSP第二个字是复位向量程序入口。Bootloader跳转时需要将MCU的VTOR向量表偏移寄存器设置为应用程序的向量表地址。检查Bootloader的跳转代码通常是bl_user_entry()或类似函数是否正确地设置了VTOR。在MCU-Boot源码中这个操作通常是自动完成的但如果你做了深度定制需要确认。时钟与外设初始化 Bootloader可能已经初始化了系统时钟和一些外设如UART。跳转到应用程序后应用程序不应假设所有外设都处于复位状态。一个稳健的做法是在应用程序的main()函数最开始重新初始化所有你需要用到的核心外设至少是系统时钟。看门狗Watchdog 检查Bootloader是否使能了看门狗且未喂狗。如果Bootloader使能了看门狗并在跳转前没有禁用它应用程序必须在超时前及时喂狗否则会导致不断复位。5.3 数据校验失败CRC错误或编程验证失败在使用write-memory命令时可能会报告CRC校验失败或编程验证错误。电气干扰 长距离、无屏蔽的串口连接容易引入噪声导致数据错误。确保通信环境良好线缆质量过关。启用BL_FEATURE_CRC_CHECK正是为了应对这种情况。波特率过高 在长线或干扰环境下过高的波特率如921600可能不稳定。尝试降低波特率到115200甚至9600。Flash编程算法 Bootloader内部的Flash驱动驱动层可能有问题。确认bootloader_config.h中关于Flash驱动的配置如BL_FEATURE_FLASH_SECURITY等与你的芯片型号匹配。可以尝试用调试器直接通过JTAG接口编程同一个二进制文件如果成功则问题很可能在Bootloader的Flash驱动部分。内存范围 确保你擦除和编程的地址范围是有效的用户Flash区域没有触及受保护的区域如Flash配置字段或根本不存在的地址。5.4 如何更新已部署产品的固件现场升级这是Bootloader的终极价值所在。你需要设计一个完整的现场更新机制应用程序中的Bootloader调用 在你的用户应用程序中预留一个入口如通过特定串口命令、按键组合或网络指令来调用Bootloader。MCU-Boot源码通常提供一个bl_user_entry()之类的API你可以在应用程序中直接调用它从而重新进入Bootloader模式等待主机连接升级而无需物理复位。双映像Dual Image与回滚 为了升级安全高级的Bootloader会支持A/B分区。当下载新固件到B分区后进行校验校验成功后再将启动标志切换到B分区。如果新固件启动失败可以自动回滚到A分区。这需要在Bootloader中实现更复杂的逻辑并规划好Flash分区。通信协议与安全 对于通过公共网络如4G、Wi-Fi进行的无线升级FOTA必须在应用层设计可靠的传输协议如分段、校验、重传并强烈建议引入加密和签名验证防止固件被篡改。从理解Bootloader的三种形态到深入bootloader_config.h进行精准定制再到亲手编译、烧录并通过两种工具完成更新我们走完了Kinetis Flashloader从概念到实践的全过程。其中最关键的是地址规划和配置匹配——你的应用程序链接地址、Bootloader的跳转地址、主机工具的写入地址这三者必须构成一个自洽的链条。而调试的起点永远是确认最基本的硬件连接和Bootloader程序本身是否已就位。在实际产品开发中我倾向于将Bootloader做得尽可能精简和稳定只保留最必要的UART接口和编程功能。对于现场升级则会设计一个更复杂的、位于应用程序内部的升级代理由它来负责新固件的下载、校验和切换Bootloader只作为最后一步的“编程执行者”。这样既能降低Bootloader的复杂度又能提高升级流程的灵活性和可靠性。希望这些经验能帮助你更好地将Flashloader集成到自己的项目中让固件更新不再是难题。
