STM32N6 FSBL启动签名与外部Flash烧录调试全链路解析

简介：围绕STM32N6启动机制与FSBL框架的专题文档，面向从事ARM架构MCU开发、希望理解片内BootROM、外部Flash启动及镜像签名流程的工程师与技术爱好者，也可作为中级嵌入式开发者熟悉新芯片启动体系的参考材料。内容从Dev boot与Flash boot/Serial boot两种启动模式切入，梳理仅运行FSBL、FSBL装载并运行应用、以及XiP就地执行三条典型路径，并解释BootROM验证Header、将FSBL搬运至内部SRAM2地址处、跳转应用或外部Flash执行等关键环节，涵盖二进制镜像签名与外部Flash编程等实践点。文档还说明ST签名工具的配置方法、Cut版本差异与BootROM最大拷贝512KB带来的工程约束，并结合IAR与STM32N6 DK板给出示例项目开发教程和注意事项。读者可据此建立从启动配置、镜像签名到部署调试的整体认知，也能排查签名失败、镜像超限和启动路径选择等问题。资源包为1个PDF文件，约2.07MB，已有162人学习。

1. 从 0x34180000 说起：为什么 STM32N6 的第一次点灯要过三道关

STM32N6 是带 NPU 的一颗 Cortex-M55 MCU，片内 ROM 只放了一小段引导程序，用户代码必须落在外部 Flash，或者通过 USB/UART 串口现灌。于是 Boot 被硬生生拆成两段，第一段就是 FSBL（First Stage Boot Loader）。很多人第一次上手会卡在 Binary Signing 和 Flash Programming 上：代码在 Dev boot 下跑得好好的，切到 Flash boot 就一片安静。这份 15 页的本地应用笔记把启动模式、三种工程架构、签名参数、IAR 调试和外部 Flash 烧录串成了一条完整链路，适合手上有 DK 或 Nucleo 板、正准备第一次点灯的开发者，也适合已经能调试、但一上外部 Flash 就翻车的人。

2. 启动链路拆解：BootROM 校验的那 1024 字节头到底装了什么

把这颗芯片的 Boot 想成一场接力：第一棒是固化在 ROM 里、改不了的 BootROM，第二棒才是你能编译、能签名的 FSBL。理解这场接力的交接规则，比记住某个按钮在哪重要得多，因为后面 90% 的“上电没反应”都能回溯到这几步里的某一步没对齐。

2.1 两种启动模式：BOOT1 引脚划出的分岔口

DK 板上那颗 BOOT1 引脚决定了上电后走哪条路。BOOT1 = 0、BOOT0 = 0 是 Flash boot，BootROM 会去外部 Flash 的固定映射区读 FSBL 的头部做校验；BOOT1 = 1 是 Dev boot，BootROM 直接把控制权交给内部 RAM，等调试器通过 SWD 把代码塞进去再跑。这两条路不是“差不多”，而是从寻址方式到校验逻辑全都不一样。

Dev boot 之所以是开发期的默认姿势，是因为它绕开了三件麻烦事：不用签名、不用 External Loader、不用保证外部 Flash 焊接和时序都正常。代价是断电即失，代码只在 RAM 里活着。Flash boot 反过来，一切都要齐备才能跑起来，任何一环缺失，现象都是同一个——板子安静得像没上电。

注意：Serial boot 的具体引脚组合在不同板型上可能不同，以手上板子的原理图和对应的应用笔记为准，别照抄别人的跳线照片。

2.2 BootROM 的三个固定动作：验头、搬运、跳转

Flash boot 下，BootROM 干的事情非常机械。第一步，它按约定去外部 Flash 的起始位置读 1024 字节的 Header，校验签名信息是否合法、镜像类型是否为 FSBL。这 1024 字节不是可有可无的装饰，它是 BootROM 判断“这块 Flash 里的东西能不能信”的唯一凭据。校验不通过，后面什么都不发生。

第二步，校验通过后，BootROM 把 FSBL 的实体内容搬运到内部 SRAM2 的 0x34180000 地址。这个地址是硬件定死的，不会因为你工程里的链接脚本改了而改变，所以 FSBL 工程的链接配置必须和它对上，否则搬过去也是一堆错位的指令。

第三步，PC 指针跳到 0x34180000，FSBL 开始执行。从这里开始，代码就是你写的了。整个链条里，BootROM 只信任“带正确 Header 的镜像”，它不关心你的 C 代码写得多漂亮，也不关心你用 IAR 还是 Keil。

这也解释了一个常见困惑：调试阶段一切正常，因为调试器直接往 RAM 写，压根没走 Header 校验；一旦切 Flash boot，BootROM 成了唯一的入口，没签名就等于没门票。

2.3 三种工程架构：纯 FSBL、Load & Run、XiP

文档把工程组织方式分成了三类，这个分类是后面所有选型讨论的基础，值得逐一对齐。

第一种是纯 FSBL，也就是整个应用就是一个 FSBL 工程，应用程序和引导逻辑编译在一起，签名后直接烧进外部 Flash。BootROM 搬运完，PC 跳进去就开始跑你的业务代码，中间没有第二次跳转。这种结构最省事，调试和部署的代码是同一份，心智负担最小。但它有一个硬上限：BootROM 最多只能搬运 512K 字节。工程一旦超过这个体积，链接能过、签名能过，上电却跑不起来。

第二种是 FSBL + Load & Run。FSBL 本体很小，只负责把外部 Flash 里应用程序的完整内容——包括 code 段和 data 段——拷贝到内部 SRAM，然后再跳转到 APP 的入口。这种结构突破 512K 限制的思路不是“让 BootROM 搬更多”，而是“让 FSBL 当二传手”。代价是 RAM 占用会明显上升，APP 有多大，SRAM 里就得腾出多大的地方，还要额外算上拷贝过程中的栈空间。

第三种是 FSBL + XiP（Execute in Place）。FSBL 把外部 Flash 配置成内存映射模式，然后直接把 PC 跳到外部 Flash 里 APP 的第一条指令，代码不搬家，就地执行。这种方式 RAM 占用最小、启动最快，但对片外 Flash 的读性能、时钟配置和 cache 策略非常敏感。配置不到位，程序能跑但性能惨不忍睹，或者在某些时序边缘的 Flash 上随机取指失败。

选型上我一般这么判断：先看编译出来的 bin 有多大，512K 以内且没有特殊 RAM 执行需求，就走纯 FSBL，别给自己找事；超了 512K，再评估 SRAM 余量，够就 Load & Run，不够才上 XiP。XiP 不是“更高级”，它只是另一种权衡，把复杂度从 RAM 转移到了 Flash 控制器配置上。

提示：判断工程体积时看的是签名前的原始 bin，不是 hex，也不是加了 1024 字节 Header 之后的 trusted bin。三者差别不小，用错文件容易得出错误结论。

3. Binary Signing 实操：-hv 2.1 和 -hv 2.3 选错就白签

签名这一步是整条链路里最容易“看起来做了其实没做对”的环节。命令敲下去有输出、文件也生成了，但上电就是不启动，因为 Header 版本和芯片的 Cut 版本对不上，BootROM 校验时直接判死。这一章把工具准备、两条命令、每个参数的含义和验证方法拆开讲。

3.1 工具准备：PATH 里必须有那个 exe

签名工具随 CubeProgrammer 一起安装，可执行文件名是STM32MP_SigningTool_CLI.exe。它默认不在系统 PATH 里，所以第一件事是把它的所在目录加进 Windows 环境变量 PATH，否则你在工程目录下敲命令只会得到“不是内部或外部命令”。

加完之后别急着签，先验证一下能不能找到：

# Windows CMD / PowerShell 通用，确认签名工具在 PATH 中可见 where STM32MP_SigningTool_CLI.exe # Linux 环境下用 which which STM32MP_SigningTool_CLI

where会打印出完整路径。如果返回空或者提示找不到，说明 PATH 没生效，常见原因是改完环境变量没重开终端。这一步看似废话，但它是后面所有命令能跑起来的前提，我见过不止一次卡在这里的。

3.2 两条命令：按 Cut 版本二选一

签名命令本身不长，区别只在-hv这一个参数。Cut 1.1 的芯片用 2.1，Cut 2.0 的芯片用 2.3，两条命令不能混用。

# Cut 1.1 芯片：Header 版本 2.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 芯片：Header 版本 2.3 STM32MP_SigningTool_CLI.exe -bin FSBL.bin -nk -of 0x80000000 -t fsbl -o FSBL-trusted.bin -hv 2.3 -dump FSBL-trusted.bin

第一条命令里的FSBL.bin是编译器直接吐出来的原始镜像，没有头；FSBL-trusted.bin是签名之后的产物，比原始文件大 1024 字节，多出来的就是 BootROM 要校验的那段 Header。-dump会把刚写进去的 Header 内容打印到终端，等于当场给你一份回执，建议每次都带上，出问题时不用靠猜。

怎么确认自己的芯片是哪个 Cut？看芯片表面的 Rev Code 丝印，对照文档里的版本对照表。这一步不能省，也不能靠“板子买得晚所以肯定是新版本”这种推断，我见过因为这条推断翻车的案例。

3.3 参数逐项拆解：改哪个、为什么改

真正需要动手的只有-bin和-hv两个。-bin指向的必须是当前这次编译的产物，别拿着上一次的旧 bin 去签，然后纳闷为什么改的代码没生效——这种低级错误在赶进度的时候特别容易犯。-hv前面说过了，跟着芯片走。

-nk这个参数值得单独说一句。它表示不使用密钥，走的是无密钥签名路径，开发阶段用着没问题。如果你的项目后续要启用安全启动，这一项就得换成带密钥的流程，那时候签名命令会变长，还需要管理密钥文件，属于另一个话题了。

3.4 签名结果的自检：差 1024 字节就是对的

签完之后别急着烧，先做两个检查。第一，比较文件大小，trusted bin 应该比原始 bin 正好大 1024 字节。第二，看-dump打印出来的 Header 内容，确认版本号和预期一致。

# 对比签名前后的文件大小，差值应为 1024 字节 ls -l FSBL.bin FSBL-trusted.bin

这个检查看着简陋，但能拦住两类高频问题：命令跑失败了但没注意看报错，输出文件其实是上一次的旧文件；以及-hv写错导致工具报错退出，文件根本没生成。用文件大小和修改时间双重确认，比盯着终端输出可靠。

提示：签名是可以重复做的。原始 bin 每次编译都会变，所以每次改完代码重新编译后都要重新签名，别指望签一次管到底。把签名命令写成一个批处理脚本，编译完顺手跑一下，能省掉大量遗忘。

4. Dev boot 调试链路：IAR 9.30 下把 UART 例程跑出第一行字

前面讲的是 Flash boot 那条路，但真正写代码的时候没人会一直在外部 Flash 上折腾，太慢。正常节奏是先切 Dev boot，在 RAM 里把功能调通，最后再走签名加烧录。这一章按顺序走一遍：进模式、配工程、编译、调试，每一步都给出判断标准。

4.1 进入 Dev 模式：先把板子拨到能灌代码的状态

DK 板和 Nucleo 板的拨码位置不一样，但目标一致：让 BOOT1 处于 Dev boot 对应的位置。改完拨码之后重新上电，这时候板子不会执行任何已有程序，就等着调试器连上来。

判断有没有进对模式，最直接的办法是不接调试器直接上电——如果板子毫无反应（串口没输出、指示灯不闪），说明它确实停在等代码的状态。如果它跑起来了旧程序，那就是拨码没生效或者没重新上电。

这一步的坑在于“改了拨码但没断电重启”。有些板子的 BOOT 引脚是上电锁存的，运行中拨动不起作用，必须断电再上电才认。

4.2 工程选项三件事：Device、ST-LINK、Output

打开 SDK 里的 UART 例程，路径是Projects\STM32N6570-DK\Examples\UART\UART_HyperTerminal_IT。这个例程整个就是一个 FSBL 工程，对应前面说的第一种架构，适合拿来理解最小闭环。

第一件事确认 Device。IAR 的器件列表里必须能选到 STM32N6 系列，如果没有，说明器件支持包没装全，需要先补上对应补丁。选错器件的直接后果是链接脚本里的内存布局不对，程序能编译但跑起来行为诡异。

第二件事配 ST-LINK。接口选 SWD，速度按默认来即可。这里的重点是调试器固件版本不要太旧，太旧的固件对新型号支持不好，表现为连不上或者连上就断。

第三件事看 Output。确认勾选了生成 bin 文件，因为后面签名和烧录都要用 bin，只有 hex 是不够的。输出目录建议固定，别让不同配置的产物混在一起。

4.3 编译前的补丁检查与 Software Reset

编译之前有个容易被跳过的前提：工具链对新芯片的支持。文档里给的版本是 IAR 9.30.1 和 Keil 5.41.0.0，如果你的版本低于这个，先升级或者打补丁。补丁包就在 SDK 的固定目录里，装完重启 IDE 才生效。CubeIDE 用户则是更新 IDE 版本，不是打补丁。

# 补丁包通常在 SDK 的固定子目录下，进目录看一眼有没有对应工具链的包 ls Utilities/CPU_Support_Pack/

这段命令只是列目录，作用是确认补丁包存在、版本对得上你的 IDE。装补丁这件事的坑在于“装了但没重启”，IDE 在启动时加载器件描述，运行中装包不会立刻生效，表现为器件列表里依然找不到 N6。

编译本身选默认选项就行，不用额外加优化等级。第一次编译通过之后，重点转到调试配置：Debugger 里的 Reset 方式必须设成 Software。

这一项是整个 Dev boot 调试里最玄学的地方。设成 Hardware 或者 Core，点下调试按钮后程序可能直接跑飞，或者停在一个莫名其妙的地址。原因是这颗芯片的复位行为和传统 MCU 不一样，硬件复位会把 BootROM 重新拉起来走一遍流程，而 Dev boot 下你期望的是“别动，让我直接灌”。改成 Software 之后，调试器用软复位方式接管，程序才能正常停在 main。

改完这个设置，退出调试会话，重新下载一次，然后再启动调试、点运行。串口终端上应该能看到例程打印的内容。到这一步，Dev boot 的链路就算通了，你有了一个可以反复修改、单步、打断点的baseline。

注意：调试阶段不需要签名。很多人在这一步习惯性去签名，然后疑惑为什么签了还是不启动——因为 Dev boot 根本不看 Header，签名是 Flash boot 才需要的动作。两件事分开理解，能省下大量无效排查。

5. 外部 Flash 烧录与排查：0x70000000 地址、External Loader 和五类翻车现场

Dev boot 跑通只是拿到入场券，真正交付要落到外部 Flash。这一步涉及外部存储器，链路比片内 Flash 长得多：调试器要通过 External Loader 认识板子上的那颗 Flash 型号，再通过它把数据写进去。任何一环不匹配，报错信息都很含糊。

5.1 External Loader：让调试器认识板外的存储器

片内 Flash 的烧录算法是 IDE 自带的，片外 Flash 不是。调试器默认不知道你板子上焊的是哪颗、用什么命令写、扇区怎么擦，这些信息全部封装在 External Loader 文件里。DK 板和 Nucleo 板随板提供对应的 loader，自己的板子就得自己开发，这是另一个工程了。

用命令行烧录前，要把 loader 的路径放进环境变量，文档里用的变量名是DKEL。这个变量名是约定，不是随便起的，命令里会直接引用它。

# Linux：把 DKEL 指向 External Loader 文件 export DKEL=/opt/tools/ExternalLoader/N6-DK-ExternalLoader.stldr # 确认变量已生效，应打印出完整路径 echo $DKEL

# Windows PowerShell：同样的变量，写法不同 $env:DKEL = "C:\Tools\ExternalLoader\N6-DK-ExternalLoader.stldr" Write-Output $env:DKEL

echo或Write-Output这一步不是多余。变量没设上、路径写错、路径里有空格没加引号，三种情况在后续命令里的表现都是同一句“loader 找不到”，回头查很费时间。先把变量本身验证对，再往下走。

5.2 命令行烧录：-w 后面那个地址是关键

变量设好、STM32_Programmer_CLI所在目录也加进 PATH 之后，就可以烧了。烧录前板子要处于 Dev 模式，这一点和调试时一样。

# Linux：连接 SWD，指定 External Loader，烧完硬件复位 STM32_Programmer_CLI -c port=SWD mode=HOTPLUG ap=1 \ -el $DKEL \ -hardRst \ -w FSBL-trusted.bin 0x70000000

# Windows：命令结构完全一致，只是变量引用方式不同 STM32_Programmer_CLI.exe -c port=SWD mode=HOTPLUG ap=1 ` -el $env:DKEL ` -hardRst ` -w FSBL-trusted.bin 0x70000000

最后那个0x70000000是外部 Flash 的映射起始地址，也是 BootROM 在 Flash boot 下会去读 Header 的位置。地址写错，数据就烧到了别的地方，芯片上电照样找不到东西。

注意：强烈建议用 bin 加显式地址的方式烧录，而不是直接烧 hex。工程编译出来的 hex 里记录的默认地址通常是内部 RAM，直接烧进去等于把程序写到了掉电就丢的地方，重启当然不启动。这个坑的迷惑性在于烧录过程一切正常、没有任何报错。

5.3 CubeProgrammer 图形化烧录：参数要对齐

不想敲命令的话，图形界面也能完成同样的事，但几个下拉框必须选对。先把 BOOT1 拨到 Dev 模式，连上 CubeProgrammer，然后在 External Loader 列表里选与板型匹配的那一项。这一步选错，后面所有操作都会失败，报错通常是读不出 Flash ID。

烧 hex 和烧 bin 在界面上的操作不一样。hex 里自带地址信息，选文件直接下就行，但前提是这个 hex 的链接地址确实指向外部 Flash，而不是 RAM。bin 没有地址信息，必须在界面上手动填0x70000000，这个输入框很容易被忽略，空着点下载就会报地址非法。

界面操作的优点是直观，每个步骤的结果都能看到；缺点是不容易脚本化，量产或者反复烧录时效率低。我的习惯是调试期用界面，确认参数组合正确之后，把对应的命令行抄下来做成脚本。

5.4 五类翻车现场：现象、原因、解决

第一类，Dev boot 下运行正常，切到 Flash boot 后完全没反应。原因基本是没签名，或者签名用的-hv和芯片 Cut 版本不匹配，BootROM 校验头就失败了。解决办法是重新签一次，把-dump的输出和芯片丝印对照确认。

第二类，烧录报错说找不到 loader，或者读 Flash ID 失败。原因通常是DKEL变量没设、路径含空格没处理，或者 loader 文件本身和板子上的 Flash 型号不匹配。解决是把变量单独 echo 出来验证，再用绝对路径重试。

第三类，烧录成功、重启无输出，但签名和地址都确认没问题。这时候要怀疑是不是烧了 hex 而不是 bin，hex 里的地址指向 RAM，数据根本没落到外部 Flash。换 bin 加显式地址重烧一次即可。

第四类，调试时下载正常，一点运行就跑飞或者停在异常地址。原因几乎都是 Debugger 里的 Reset 方式没改成 Software。这是 100% 可复现的配置问题，不是玄学。

第五类，自己的板子第一次烧录就失败，换 DK 板同样的镜像却能跑。原因是没有适配自己板子 Flash 型号的 External Loader，调试器根本不认识这颗存储器。这个只能老老实实开发 loader，没有捷径。

6. 上电验证：签名前后差 1024 字节，用 dump 和 attach 把黑匣子打开

烧完切回 Flash boot、重新上电，看到串口正常输出，大部分人到这里就收工了。但我建议多做两步验证，因为“这次能跑”和“下次也能跑”是两回事。

第一步验证是核对签名产物。原始 bin 和 trusted bin 的大小差必须正好是 1024 字节，多一字节少一字节都说明签名过程有问题。配合-dump打印出来的 Header 内容，确认版本号、镜像类型、目标地址三项都对得上。这套检查我一般固化成一个脚本，编译完自动跑，跑不过就不往下走。

# 签名后自动核对：文件大小差值应为 1024，并打印 Header 供人工确认 ORIG_SIZE=$(stat -c%s FSBL.bin) SIGNED_SIZE=$(stat -c%s FSBL-trusted.bin) DIFF=$((SIGNED_SIZE - ORIG_SIZE)) if [ "$DIFF" -ne 1024 ]; then echo "签名异常：差值 $DIFF 字节，应为 1024" exit 1 fi echo "签名大小校验通过，Header 版本请对照芯片 Cut 版本确认"

这段脚本做的事很简单：取两个文件的大小、算差值、不符就退出。放在编译后自动执行，能挡住“忘了重新签名”这类低级失误。stat -c%s是 GNU 版本的写法，macOS 上要换成stat -f%z，跨平台脚本里记得做兼容。

第二步验证是调试口的可用性。Cut 1.1 的芯片在 Flash boot 模式下并没有关闭调试口，这意味着程序从外部 Flash 跑起来之后，你仍然可以用调试器 attach 上去，看到当前的 PC、变量和调用栈。这对排查“上电后跑飞但不报错”这类问题极其有用——不用改代码、不用重新烧录，直接连上去看它卡在哪。

attach 的操作和普通调试不同，不要点下载，选“attach to running target”。连上之后先看 PC 是不是落在预期的函数附近，再看栈指针有没有异常。如果 PC 停在一个既不是你的代码、也不是 BootROM 的地址上，大概率是跳转地址算错了，回头查链接脚本或者 FSBL 里那次跳转。

还有个细节值得留意：Cut 版本不同，Flash boot 下调试口的行为可能不一样，别把 Cut 1.1 的经验直接套到别的版本上。每次换板子，先花两分钟确认能不能 attach，比事后猜要快得多。

从那以后，我每次签完名都强制走一遍“大小差 1024 + dump 对版本”这两步，哪怕赶进度也不跳。血泪经验换来的是：上电没反应的时候，我能立刻排除掉签名这一整类问题，把精力放在真正复杂的地方。希望帮到你。

本文还有配套的精品资源，点击获取