最近把项目从体验板往自研板迁移第一次在 STM32N6 上用 STM32CubeMX 搭 LOAD RUN 工程折腾的过程比想象中曲折不少。这块芯片和以前用的 F4/H7 差别非常明显尤其是启动路径和存储映射。这篇应用笔记对应内部项目编号 LAT1587我把整个“用 CubeMX 生成代码、改链接脚本、烧外部 Flash 再 LOAD RUN”的完整流程记录如下。如果你正准备用 STM32N6 做产品开发这篇内容能帮你避开至少一半的坑。文章会覆盖三件事为什么 LOAD RUN 是 STM32N6 产品化的常规形态、CubeMX 里最关键的几个配置项怎么填、以及从生成代码到真正在板子上跑起来之间那些文档里不会写明的细节。适合正在用 STM32N6 做评估、或者刚拿到 N6 开发板打算跑第一个工程的开发者阅读。1. 项目背景与核心思路拆解1.1 为什么 STM32N6 的工程形态和传统 MCU 不一样先说说 STM32N6 这块芯片的特殊性。它用的是 ARM Cortex-M55 内核主频能上到 600MHz 甚至更高而且内部还集成了 NPUNeural-ART 加速器。这意味着它不是为了控制而存在的 MCU而是为了视觉、AI 推理、边缘计算这类场景设计的。既然要跑模型、要驱动摄像头、要处理图形代码和数据的体量就会比普通 MCU 程序大得多。STM32N6 的片上非易失存储空间不大对于 AI 应用来说远远不够所以绝大多数实际产品都会把整个应用镜像放在外部 XSPI NOR Flash 上。这也是 STM32N6 能保持灵活性、同时把引脚成本控制在可接受范围的原因之一。代码放在外部存储芯片上电后由内部 BootROM 负责初始化 XSPI 控制器再把外部 Flash 映射到内存地址空间最后跳过到应用入口执行。这个过程在 ST 语境里就经常被称作 LOAD RUN——从这里把镜像“LOAD”进来再“RUN”起来。传统 MCU 开发时我们习惯直接通过调试器把程序烧进内部 Flash然后点 Run。内部 Flash 本身就是芯片内存映射的一部分上电直接执行不需要额外初始化存储控制器。但到了 STM32N6 上外部 Flash 不能天然被 CPU 访问必须先经过 BootROM 引导、XSPI 初始化、内存映射这些步骤。所以如果不开 LOAD RUN 这种工程形态你的程序就算成功烧进外部 Flash上电后也不一定跑得起来。1.2 “Debug Run”和“LOAD RUN”的本质区别在 STM32 的开发习惯里工程通常有两种形态一种是只用于开发调试的 Debug/RAM 工程代码会被下载到内部 RAM 或内部 FlashIDE 通过调试器控制程序执行另一种是所谓的 LOAD RUN 工程生成的镜像会被加载到外部 Flash上电后由芯片自己完成引导和运行。我把两者的差异整理成了一张对比表对比维度传统 Debug 工程LOAD RUN 工程镜像存放位置内部 RAM / 内部 Flash外部 XSPI NOR Flash启动路径上电或复位后 CPU 直接从内部地址取指上电后 BootROM 先初始化 XSPI再把外部 Flash 映射进来运行速率内部 RAM 执行速度快依赖 XIP 映射和 Cache配置不当会明显变慢适用场景开发调试、单步跟踪产品固件、量产烧录、用户现场升级工程修改重点基本不用改链接脚本必须修改链接脚本和启动流程最终产品里跑的一定是 LOAD RUN 形态因为用户不可能给每个设备都接一个调试器。我在 STM32N6 上的习惯是前期调试用 RAM 工程功能稳定后立刻切到 LOAD RUN 工程验证真实启动链路后者才是决定项目能不能量产的关卡。1.3 LAT1587 笔记想解决什么问题LAT1587 这份应用笔记核心目标就是用 STM32CubeMX 完整创建一个 STM32N6 的 LOAD RUN 工程。它把 CubeMX 能帮我们做的和必须自己动手的部分切分得很清楚。CubeMX 负责生成外设初始化代码、时钟树配置、引脚复用配置但链接脚本、启动文件的调整、外部 Flash 烧录以及启动模式验证这些环节还是需要开发者手动的。初次接触 STM32N6 的团队通常会在两个地方卡住第一不知道 CubeMX 里的 XSPI 和内存映射应该怎么配置第二生成完代码后链接脚本没改导致编译出来的镜像链接地址和实际运行地址不一致上电直接 HardFault。这份笔记重点就是为了把这两条主线理清楚。我建议在动手之前先确认一个原则工程里所有地址的设定都必须围绕“CPU 从哪里取第一条指令”这个核心问题展开。2. 环境准备CubeMX、器件包与 IDE 清单2.1 版本要求与安装注意事项STM32N6 是比较新的器件CubeMX 老版本不支持所以第一步就是把工具链更新到能识别 N6 的版本。我目前使用的新版 CubeMX6.13 之后的版本已经能直接搜索到 STM32N6并在新建工程时自动提示安装对应固件包。如果安装的是老版本建议先更新工具再考虑工程。STM32CubeMX 安装本身没什么难度但有两个点需要注意。第一CubeMX 下载固件包时需要联网并且在首次安装 STM32N6 器件支持时文件较大网络不稳定会导致下载失败。国内网络环境下如果总是下载中断可以考虑从官网下载离线安装包后手动导入。第二固件包安装路径不要用中文或带空格的路径后面生成工程、调用工具链时可能会出现奇怪的路径解析问题。除了 CubeMX还需要准备 STM32CubeProgrammer用来烧录外部 Flash和至少一款 IDE。我这边用 STM32CubeIDE因为和 CubeMX 配合最顺生成工程后直接双击打开。如果你团队习惯用 IAR 或 KeilCubeMX 也支持生成对应工程但下面遇到链接脚本问题时不同 IDE 的配置方法会略有差异。2.2 新建工程时的初始选项打开 CubeMX 后在 MCU Selector 里搜索 STM32N6 系列选择你手上板卡对应的具体型号。我手上的板子是 N6570 系列带外部 OctalFlash所以选型时优先选择带 XSPI 引脚的封装。如果你用的是官方开发板比如 N6570-DK直接在 Board Selector 里搜型号即可CubeMX 会自动带入大部分引脚配置省去不少手工分配的工作。新建工程时还需要选择目标 IDE 类型比如 STM32CubeIDE、EWARM 或 MDK-ARM。这个选项决定了 CubeMX 生成的是 .project 文件还是 .ewp 工程文件。我建议如果团队没有特别偏好直接用 STM32CubeIDE因为它在代码生成后的路径处理和外设配置兼容性上最省心。在创建工程这一步还有一个容易被忽略的选项是“Project Settings”里的链接脚本设置。CubeMX 默认生成的工程会把代码放在内部执行地址这对 LOAD RUN 来说是不够的。所以创建完初始工程后不要急着生成代码先到时钟和存储配置页面把整体框架定下来。3. STM32CubeMX 关键配置实操3.1 时钟与电源配置先把核心频率跑稳STM32N6 的时钟树比 F4/H7 复杂主频高又有多个独立时钟域CPU、NPU、总线矩阵、外设。在 CubeMX 的 Clock Configuration 页面默认可能只有外部晶振输入还没配置 PLL所以第一步是把系统时钟来源设到 HSE 外部晶振然后通过 PLL 倍频到目标频率。我这边 HSE 用的是 25MHz 晶振PLL 配置后让 SYSCLK 跑到 600MHz。CubeMX 的时钟树页面会自动检查分频/倍频系数是否合法如果出现红色提示多半是某个外设需要的最大频率超限了。这时代码还没生成先回到外设配置页降低对应外设时钟分频避免生成后因为时钟越界导致启动不稳定。NPU 时钟也需要单独确认。STM32N6 跑 AI 模型时NPU 频率会影响推理性能但频率越高对电源和温度要求也越高。我这边的经验是先按官方默认频率跑通工程再根据实际模型性能逐步往上调。时钟配置完成后记得去 Power 页面确认电压档位和工作模式STM32N6 在高频运行时会自动切换电压域如果配置不匹配代码可能能烧进去但运行时会随机复位。3.2 XSPI 与外部 Flash 配置让外部存储被芯片看见STM32N6 的 LOAD RUN 最关键的外设就是 XSPI。CubeMX 中把 XSPI 使能后需要选择 Memory Mapped modeXIP 模式也就是把外部 Flash 直接映射到 CPU 地址空间。格式上我选择单 OctalSPI 模式数据线 D0-D7加上 DQS 信号用于高速读取。如果选双 Flash 交错模式带宽更高但工程复杂度也会翻倍初学阶段不建议。在参数配置里Flash 类型选择 Macronix 或其他对应厂商的 NOR Flash。时序参数要根据你板子上实际焊接的 Flash 型号查询数据手册填写。CubeMX 提供了一些预设选项但强烈建议不要直接套用引脚延展性、Dummy Cycle、读命令代码这些参数在启动阶段一旦出错BootROM 根本读不出有效指令现象就是上电后完全没有反应。地址映射方面N6 会把 XSPI 映射到高地址段。为了保险我通常会记住这个原则外部 Flash 的映射起始地址由芯片手册里的内存映射表决定而不是由我们自己决定。所以链接脚本里的执行地址必须和 XSPI 映射地址保持一致。从 N6 的中断向量表到启动代码入口全部要在映射后的地址段内偏移。引脚分配在 CubeMX 里基本是自动完成的只需要确认 XSPI 信号没有和其他外设冲突。N6 引脚复用引脚多如果同时要用摄像头、SDIO、UART这一步特别容易打架。我建议在分配 XSPI 引脚时先固定一组连续可用的引脚再分配其他外设减少布线难度。3.3 TrustZone 与安全属性应用安全区和非安全区怎么处理STM32N6 支持 TrustZone-M这是 ARMv8.1-M 内核的安全扩展。热词里提到的“应用安全区和应用非安全区”功能切换到工程层面就是能不能在 CubeMX 里开启 TrustZone并生成安全工程和非安全工程两套代码框架。如果你不需要安全启动、安全存储或者代码隔离直接在 Project Manager 里把 TrustZone 关闭工程会简化很多。但如果你的产品需要保护算法、密钥、固件下载验证那就必须开启 TrustZone并规划好安全区和非安全区在内存地址上的划分。开启 TrustZone 后CubeMX 生成出来的是一个安全的工程和一个非安全的工程两部分通过 SAUSecurity Attribution Unit和 IDAU 进行地址属性划分。LOAD RUN 在这种模式下要考虑的不只是外部 Flash 映射还要确保安全区代码能够访问非安全区地址非安全代码不能越界访问安全区。一个我在实践中踩过的坑是检查代码时一定不要把安全区内存配置到外部 Flash 的映射地址之外否则第一次启动时 SAU 配置还没生效跳转就会 HardFault。3.4 额外建议TRACE 调试口和 Cache 配置LOAD RUN 的一个潜在问题是外部 Flash 比内部 RAM 慢很多如果没有任何缓存机制程序跑起来会明显卡顿。STM32N6 内部有 I-Cache 和 D-Cache在 CubeMX 里明确使能并在启动代码里把 Cache 初始化好。外部 XSPI 在 XIP 模式下配合 Cache能达到接近内部 Flash 的执行速度这是 LOAD RUN 在性能上能不能被接受的关键。同时我建议在 CubeMX 里把 TRACE 调试口一起配置出来。虽然 LOAD RUN 是产品形态但在开发验证阶段串口日志和 SWO 输出仍然是排查问题最直接的手段。CubeMX 生成的代码默认不开启 TRACE需要到 Debug 配置里选好 trace 异步模式并分配对应引脚。工程跑起来后你会发现这几个配置孔花的时间非常值得。4. 生成代码、链接脚本调整与编译烧录4.1 从 CubeMX 生成工程到 IDE 的完整流程在 CubeMX 里把 3.1~3.4 的配置全部做完回到 Project Manager 页面填好工程名、工具链和代码生成选项。生成代码前务必再检查一遍三个位置外设初始化顺序、堆栈大小、以及是否生成了 .ld 链接脚本文件STM32CubeIDE 工具链会生成IAR 生成的是 .icfMDK 生成的是 .sct。不同 IDE 的链接脚本文件格式不一样但核心修改思路完全一致把可执行段的起始地址改到外部 Flash 映射地址。点击 GENERATE CODE 后用 STM32CubeIDE 打开生成的工程。这时候直接编译大概率能通过但烧到板子上却不一定能运行。原因就是链接脚本里的地址还是为内部执行准备的LOAD RUN 真正开始动手的地方从这一步才开始。4.2 链接脚本调整LOAD RUN 最关键的一步在 STM32CubeIDE 里打开生成的 .ld 链接脚本找到 FLASH 或内存区域定义部分。传统 MCU 工程的 FLASH 起始地址是 0x08000000 之类的但 STM32N6 的 LOAD RUN 工程要把它改成外部 XSPI 映射的起始地址比如 0x70000000 这个段。需要注意的是这个地址并不是所有 N6 都千篇一律具体以你板卡的 XSPI 映射表和芯片手册为准。整段链接脚本的核心其实就是三件事代码段能放在外部地址、数据段初始化能从外部地址读取、堆栈段放在 RAM 或内部地址。我给出的经验是代码段和只读数据段放外部 Flash可写数据段和堆栈放内部 RAM。这样既能享受外部存储的大容量又不会因为外部 Flash 随机写入性能太差而拖慢全局变量访问。如果只是简单粗暴地把所有段都塞到外部 Flash系统初始化时变量拷贝阶段就会非常慢严重时甚至会触发看门狗复位。一个常见错误是中断向量表没有重定位。Cortex-M 系列的向量表默认在 0x00000000但 STM32N6 上第一条指令从外部 Flash 映射地址开始执行后向量表必须被放到实际运行地址处否则任何中断触发都会跳到错误位置。工程里需要把 SCB-VTOR 设置到外部 Flash 起始地址并确保向量表对齐通常是 0x400 字节或更大对齐具体看芯片要求。启动流程上STM32N6 的 BootROM 会把很多底层初始化做掉但我们自己编译出来的 Cortex-M 启动文件仍然需要正确执行包括堆栈指针初始化、数据段拷贝和 BSS 段清零。这些操作需要链接脚本里的符号表支持因此改 .ld 文件时最好保留原有符号定义只改内存区域不要自己重写整个脚本。4.3 用 STM32CubeProgrammer 烧录外部 Flash 并运行工程编译成功后生成的可执行文件还不能用默认方式烧录。因为默认烧录是针对内部存储的算法STM32N6 的 LOAD RUN 工程要写外部 Flash必须让 STM32CubeProgrammer 使用对应的外部编程器.stldr 文件。用 STM32_Programmer_CLI 来烧录的话命令大概是这样的STM32_Programmer_CLI -c portSWD modeHOTPLUG -el external_flash_loader.stldr -d build/Debug/YourProject.elf其中-el指定外部 Flash loader 文件这个文件可以从 STM32CubeN6 固件包的 Utilities 目录里找到也可以根据自己板卡 Flash 型号定制。烧录完成后把板卡的 BOOT 引脚配置到从外部 Flash 启动的模式复位一次LOAD RUN 就真正跑起来了。这里有一个很关键的验证点程序上电后能不能自动运行和 IDE 里按 Debug 运行是两回事。IDE 的 Debug 模式会通过调试接口接管 CPU掩盖很多启动问题。而 LOAD RUN 模式是脱离调试器完整走一遍 BootROM 到应用入口的流程。如果烧录完后复位没有任何反应先别急着怀疑程序逻辑优先查启动链路配置。烧录还有个细节外部 Flash 的起始地址有保护机制时首次烧录前可能需要先执行全片擦除。CubeProgrammer 的-e参数可以控制擦除范围如果不小心把 Flash 里的出厂固件也擦了后面想恢复默认出厂状态会很麻烦。所以建议先读出原始 Flash 内容做备份再开始烧录。5. 常见问题与排查技巧实录5.1 烧录成功后复位的常见问题定位LOAD RUN 工程最常见的现象是程序烧进外部 Flash 成功但按复位键后屏幕上没有任何反应LED 也不闪。遇到这种情况我一般按四条线排查第一确认 BOOT 引脚状态是否真的选中了外部 Flash 启动第二确认 XSPI 时序参数和 Flash ID 是否和实际 Flash 匹配第三检查链接脚本的起始地址和实际映射地址是否一致第四查看复位后调试器能不能停在 Main 函数入口。如果调试器能连上比较快的办法是用 STM32CubeProgrammer 读一下 PC程序计数器寄存器的当前值。如果 PC 停在 0xFFFFFFFE 或 0x00000000 附近多半是取指失败要么是外部 Flash 没有正确映射要么是向量表地址不对。如果 PC 已经跳到外部 Flash 映射段但死循环那大概率是启动文件里的数据段初始化没过检查 .ld 文件里 LMAload memory address和 VMAvirtual memory address的关系。5.2 外部 Flash 执行速度慢和 Cache 问题LOAD RUN 跑起来之后很容易发现程序执行速度明显偏慢这通常是 Cache 没初始化。XIP 模式下 CPU 每次取指都要访问外部 Flash没有 Cache 时性能会惨不忍睹。STM32N6 内部缓存使能后别忘了在系统初始化阶段调用 SCB_EnableICache() 和 SCB_EnableDCache()并且在 CubeMX 里确认 XSPI 的读写时序满足缓存行填充要求。这里有一个容易忽略的矛盾点如果 D-Cache 使能了但外部 Flash 偶尔会被写操作修改就会出现缓存一致性问题。LOAD RUN 场景下外部 Flash 主要是只读的模型参数、字体资源、配置文件都放只读区所以 D-Cache 一般可以放心开启。如果后续要在运行期动态写入外部存储那就需要配置 XSPI 或存储控制器把对应区域设置为非缓存区或者使用 cache clean/invalidate 操作。5.3 安全与非安全区地址异常 HardFault开启了 TrustZone 的工程跑 LOAD RUN常见的报错是进入 HardFault且 PC 地址落在安全属性和实际配置不一致的区域。排查方法主要看 SAU 配置安全区代码能否访问非安全区外设、非安全区中断是否被安全区正确委托。如果你使用的是 CubeMX 生成的 TrustZone 工程它默认会在启动代码里配置 SAU 寄存器不要删除这些配置。另外如果安全工程和非安全工程的链接地址分配有重叠也容易在运行到边界时触发 fault。建议把安全区的 SRAM 和非安全区的 SRAM 地址范围在工程注释里明确写出来团队成员修改内存分配时不会踩到对方区域。我在项目里甚至会在两个工程的链接脚本头部注释保留文本记录当前版本的安全/非安全地址划分方便回溯问题。5.4 问题速查表现象可能原因处理建议复位后无反应BOOT 引脚配置错误检查硬件启动模式确认选择外部 Flash 启动复位后无反应XSPI 时序参数不匹配核对 Flash 数据手册重新配置读命令与 Dummy Cycle复位后 PC 停在 0x00000000向量表未重定位设置 SCB-VTOR 为外部 Flash 映射地址进 main 后死循环链接脚本地址和映射地址不一致检查 .ld 文件里 FLASH 起始地址中断响应失败中断向量表对齐或地址错误确认向量表地址按芯片要求对齐执行速度极慢Cache 未使能使能 I-Cache/D-Cache检查 XSPI 时序HardFault 且地址异常TrustZone/SAU 配置错误检查安全/非安全地址划分确认 SAU 寄存器配置烧录时连接失败CubProgrammer 缺少外部 loader确认-el指向的 .stldr 文件路径正确排查这类问题最关键的一点是一次只改一个变量。我刚做 STM32N6 的时候遇到复位无反应同时改了链接脚本、BOOT 引脚和 XSPI 参数结果烧了一个星期都没找到问题。后来老老实实把 Flash 内容读回来对照才发现最初 XSPI 的参数就配错了后面几轮改动都是在错误基础上叠加。最后分享一个我个人的操作习惯在 CubeMX 里把 LOAD RUN 相关的配置项写进工程注释特别是 XSPI 的映射地址、时钟参数、安全区划分这三类信息。这样生成的代码在移交或者保存半年后再回看时一眼就能回忆起当初的配置意图。另外建议每个里程碑版本保存一份 CubeMX 的 .ioc 文件和对应的链接脚本回到旧版本定位问题时会非常有用。STM32N6 的 LOAD RUN 工程并不难难的是把启动路径和存储映射的每个环节都想清楚。按这个流程搭一遍你就能把精力放到真正有挑战性的业务代码上去了。