简介《LAT1491 STM32N6的FSBL基本流程介绍-v1.0》是一份面向ARM架构MCU开发者、嵌入式技术爱好者及希望深入理解STM32N6启动机制的专业人士的技术文档重点解决片内BootROM之后如何验证并加载FSBL、如何在Dev boot与Flash/Serial boot之间选择以及如何组织外部Flash应用程序并制作可启动镜像等实际问题。包内为1个PDF文件约2.07MB系统梳理BootROM对1024字节Header的校验与FSBL搬运、FSBL单独运行、FSBL加Load Run、FSBL加XiP三种典型流程同时说明ST Signing Tool的签名参数、Cut1.1与Cut2.0对应的header版本差异以及BootROM最大512KB拷贝限制等工程注意事项。文档还以IAR与STM32N6 DK板为例给出从工程创建、编译配置到下载部署的示例步骤便于读者对照完成镜像签名、Flash编程和启动异常排查并附有开发配置提示。已有162人学习可作为STM32N6启动配置、二进制签名与外部存储部署实践的参考材料适合中高级嵌入式开发者查漏补缺。1. FSBL为什么一块只带 NPU 的 MCU 要把启动拆成两段STM32N6 这类芯片有个反直觉的地方芯片内部的 ROM 只有一小段 BootROM容量很小而且写死之后无法修改用户代码必须放到外部 Flash或者通过串口临时灌进来。这和过去“Flash 就在片内、上电直接取指”的体验完全不同也是很多从传统 MCU 转过来的开发者第一次遇到问题的根因。多出来的这一段就是 FSBLFirst Stage Boot Loader第一阶段引导加载程序。它不是可选的附加功能而是对硬件约束的直接回应BootROM 只负责“信任第一段代码”剩下的搬运、配置、跳转交给 FSBL把“芯片出厂时固化、不可修改的启动能力”和“用户每次都能修改的应用逻辑”分开让支持 NPU 的这类 MCU 也能可靠地实现启动。读懂这段分层你就会明白后面那些签名、地址、XiP 到底在解决什么问题。2. BootROM 与 FSBL 的分工512K 拷贝上限决定了架构2.1 BootROM 只做三件事把 BootROM 的行为拆开看它做的事情很少读 BOOT 引脚确定启动模式验证目标镜像的头把镜像搬到指定 SRAM 地址并跳转。以外部 Flash 启动为例BootROM 会先校验 FSBL 头部那 1024 字节的 Header 信息校验通过后把 FSBL 搬到内部 SRAM2 的0x34180000再把 PC 指针指过去。这里有个容易被忽略的设计Header 是独立于代码正文的一段元数据。代码本身怎么搬、搬到哪、能不能执行全由 Header 里声明的信息决定。这意味着 BootROM 不需要理解你的代码它只认 Header。这是一种典型的“用元数据解耦”的做法ROM 固化一次后续所有启动策略的变化都落在可重新生成的 Header 上。2.2 为什么 FSBL 必须签名FSBL 必须完成签名否则无法正常启动。签名工具会在原始 bin 前面拼上 Header产物形如FSBL-trusted.bin。签名动作本质上就是把“镜像描述信息 完整性校验”变成 BootROM 能读懂的格式这也是为什么调试阶段不需要签名、而烧到外部 Flash 前必须签名——两条路径的入口不是同一个。注意签名前需要安装对应版本的 CubeProgrammer并把签名工具的路径加入系统 PATH否则命令行直接报找不到可执行文件。2.3 512K 这条硬线单 FSBL 工程也能直接包含应用逻辑编译烧录一个工程看起来最省事。但 BootROM 最大只搬 512K 字节。工程一旦超限就必须换成 FSBL APP 的两级结构FSBL 保持精简负责把 APP 完整搬到内部 SRAM含 data 和 code再跳转。这条限制不是建议而是硬性的物理约束也是三种启动架构分化的起点。2.4 三种启动架构的取舍架构搬运内容启动后执行位置适用场景仅 FSBLBootROM 搬 FSBL内部 SRAM2逻辑简单、体积在 512K 内FSBL Load RunFSBL 搬 APP 全文内部 SRAMAPP 超出 512K且可接受启动拷贝耗时FSBL XiPFSBL 只配置 Flash 为 XiP外部 Flash 原地执行APP 体积大想省 RAM 与拷贝时间Load Run 把 Appli 的完整内容搬进内部 SRAM代价是占用 RAM 且启动阶段有拷贝开销好处是执行速度稳定。XiPExecute in Place则让 FSBL 把外部 Flash 配置成可直接取指的模式完成后 PC 直接跳到外部 Flash 中 App 的第一条指令省掉整段拷贝但对 Flash 的读时序和访问延迟更敏感。选哪种本质是在 RAM 占用、启动时间、执行性能三者之间做权衡。3. 签名与镜像布局Header 里到底装了什么3.1 一条命令背后的参数语义签名命令有两种版本分支区别只在-hv的取值对应芯片的不同 Cut 版本# Cut 1.1 版本 STM32MP_SigningTool_CLI.exe -bin FSBL.bin -nk -of 0x80000000 -t fsbl \ -o FSBL-trusted.bin -hv 2.1 -dump FSBL-trusted.bin # Cut 2.0 版本 STM32MP_SigningTool_CLI.exe -bin FSBL.bin -nk -of 0x80000000 -t fsbl \ -o FSBL-trusted.bin -hv 2.3 -dump FSBL-trusted.bin各参数的含义需要逐个核对-bin指向原始未签名的 bin-nk表示不使用密钥相关选项即 no keys-of是 option flags0x80000000这个值决定了镜像的属性位-t fsbl声明镜像类型BootROM 靠它判断这是不是自己能接的第一阶段镜像-o是输出文件-hv是 Header 版本号必须与芯片 Cut 版本匹配-dump把生成后的 Header 打印出来便于核对。-hv写错是最隐蔽的一类错误命令能跑完文件也生成了但 BootROM 校验不过板子毫无反应。这里没有后悔药只能靠-dump的输出和芯片版本对一遍。3.2 Header 与前 1024 字节的关系BootROM 验证的是镜像最前面那 1024 字节。签名工具的作用就是生成这段内容并拼到 bin 前面所以FSBL.bin和FSBL-trusted.bin的大小差正好是 Header 的长度。理解这一点后很多现象就顺了比如你直接拿未签名的 bin 去烧Flash 里第一个字节就不是 BootROM 期待的格式校验自然失败。3.3 开发调试与量产启动是两条路调试阶段走的是 Dev bootBootROM 直接从内部 RAM 启动不经过签名校验。这也是为什么在 IDE 里单步调试一切正常一旦切到 Flash 启动就卡死——两种模式的入口、校验、搬运逻辑全都不同。开发时跑通不等于量产时能启动这个认知差是新手最常见的翻车点。4. 从 RAM 调试到 Flash 启动一次完整链路的机制对照4.1 Dev boot 与 Flash boot 的引脚差异启动模式由 BOOT1 引脚决定。Flash boot 对应 BOOT1 0、BOOT0 0上电后 BootROM 尝试从外部 Flash 启动Dev boot 则让 BootROM 从内部 RAM 启动。开发板上通常有跳线或按键切换切换后必须复位才能生效热切换是无效的。4.2 工程配置里几个决定性选项工程能编译通过不代表能正常下载调试。需要逐项确认的包括Device 列表中存在 STM32N6 对应型号没有就先装补丁包、ST-LINK 配置正确、Output 选项符合预期、Debugger 的 Reset 方式设为 Software。Reset 方式这一项如果留在默认的硬件复位调试会话往往起不来改完还要退出调试、重新下载、再进调试程序才能从串口正常打印。补丁包的处理也值得单独说一句Keil 和 IAR 需要装 N6 相关补丁CubeIDE 则需要更新到支持该芯片的版本。补丁包在 SDK 目录里有明确位置漏装的表现通常是器件识别异常或链接脚本报错而不是一句清晰的“缺补丁”。4.3 烧录地址hex 与 bin 的分水岭烧到外部 Flash 时建议指定地址烧 bin而不是直接烧 hex。原因很具体工程编译出的 hex 默认地址一般在 RAM直接烧进去等于把代码写到了错误的位置板子当然起不来。命令行方式如下# LinuxDKEL 为 External loader 的环境变量名 STM32_Programmer_CLI -c portSWD modeHOTPLUG ap1 -el $DKEL \ -hardRst -w FSBL-trusted.bin 0x70000000 # Windows STM32_Programmer_CLI -c portSWD modeHOTPLUG ap1 -el %DKEL% \ -hardRst -w FSBL-trusted.bin 0x70000000参数逐个说明-c portSWD modeHOTPLUG ap1指定 SWD 连接、热插拔模式、访问端口 1-el指定 External loaderDK 板和 Nucleo 板自带对应的 loader自制板需要自己开发-hardRst在下载后执行硬复位-w写入数据后面跟文件与目标地址。0x70000000是外部 Flash 的映射地址写错这个地址的后果和烧 hex 一样——代码在 Flash 里但 BootROM 找不到。如果走图形界面流程等价切到 dev 模式连接、选对应的 External loader、下载时明确指定地址。烧录前的第一件事是确认手上这个工程是不是 FSBL 工程是的话必须先签名否则从外部 Flash 启动时一定失败。4.4 重启与 Attach 调试烧录完成后把 BOOT 引脚切回外部 Flash 启动模式复位BootROM 就会从外部 Flash 走完整链路。在 Cut 1.1 版本上Flash 启动模式并没有关闭调试口可以用“attach to running target”的方式挂上去调试。这个能力在排查“为什么 Flash 启动失败”时非常有用——能挂上去说明芯片至少在跑挂不上去问题多半在 Header 校验或搬运阶段。5. 避坑清单五条血泪经验5.1 现象调试一切正常切 Flash 启动毫无反应原因FSBL 未签名或-hv与芯片 Cut 版本不匹配BootROM 校验头部失败后直接放弃启动表现为完全静默。 解决先用-dump把 trusted bin 的 Header 打出来核对版本号再确认烧进去的确实是FSBL-trusted.bin而非原始 bin。5.2 现象烧录成功但程序跑飞或进入异常原因烧的是 hex默认地址指向 RAM或者 bin 的目标地址写错了。 解决统一改成“bin 显式指定0x70000000”的方式烧录如果必须用 hex先确认链接地址已改到外部 Flash 映射区。5.3 现象工程编译过了下载后无法进入调试原因Debugger 的 Reset 方式不是 Software或者 ST-LINK 配置与实际硬件不匹配。 解决把 Reset 改为 Software退出调试会话重新下载再重新进入调试必要时检查 Device 型号是否精确对应。5.4 现象工程越做越大某天突然启动不了原因单 FSBL 工程超过了 BootROM 的 512K 搬运上限。 解决拆分架构改成 FSBL Load Run 或 FSBL XiP让 FSBL 只负责搬运或配置应用逻辑独立成 APP。这条坑的隐蔽之处在于它不会在编译期报错而是在你加了某个大数组或字库之后才发作。5.5 现象IDE 提示器件缺失、链接脚本异常原因没装 N6 补丁包或 IDE 版本过低。 解决从 SDK 指定目录安装补丁CubeIDE 则升级到支持该芯片的版本装完后重新确认 Device 列表。6. 设计取舍为什么把复杂度前移到启动阶段回头看这套机制真正的设计取舍在于“把复杂度放在哪里”。传统 MCU 把启动做成一跳直达代价是 Flash 必须和内核在同一片硅上、容量受工艺限制。N6 选择把代码赶到外部 Flash于是必须在启动早期引入一段可信代码用它去配置外部存储、搬运镜像、决定执行位置。BootROM 越小越安全因为它一旦出厂就不可修改FSBL 越灵活越好因为它可以随工程重新签名生成。这个分界点选在 1024 字节 Header 上恰好是“足够描述一个镜像”和“小到能硬编码校验逻辑”的平衡。三种架构的分化也是同一个思路的延伸。仅 FSBL 适合小工程简单但被 512K 卡死Load Run 用 RAM 换通用性启动阶段有确定的拷贝开销换来执行性能的稳定XiP 反过来用更严格的 Flash 读时序要求换掉整段拷贝适合大镜像。没有哪个绝对更好只有你的 RAM 预算、启动时间要求和 Flash 器件特性凑不凑得上。判断方法很直接先量 FSBL 和 APP 的实际体积再看 RAM 余量最后看 Flash 的访问延迟是否支撑原地取指。验证思路我一般建议按这个顺序走先在 Dev boot 下把功能全部调通再单独验证签名产物能否被-dump正确解析然后烧到外部 Flash 并 attach 观察 PC 是否落在预期地址最后才切引脚冷启动。这个顺序的价值在于每一步失败都能定位到具体环节而不是在“板子不亮”这个笼统现象里瞎猜。这套流程第一次走的时候我在-hv上栽过跟头命令跑完、文件生成、烧录成功板子一动不动排查了大半天才发现 Header 版本和芯片 Cut 对不上。从那以后我每次签名后都强制先跑一遍-dump把版本号和目标地址对一遍再往下走这个习惯省下的时间远比那一条命令多。文档里对三种启动架构和烧录地址的说明比较具体配合 SDK 里的示例工程对照着看理解会快很多希望帮到你。本文还有配套的精品资源点击获取