企业官网建设流程全解析

最近把项目从体验板往自研板迁移，第一次在 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 甚至更高，而且内部还集成了 NPU（Neural-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 或内部 Flash，IDE 通过调试器控制程序执行；另一种是所谓的 LOAD RUN 工程，生成的镜像会被加载到外部 Flash，上电后由芯片自己完成引导和运行。

我把两者的差异整理成了一张对比表：

最终产品里跑的一定是 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 的版本。我目前使用的新版 CubeMX（6.13 之后的版本）已经能直接搜索到 STM32N6，并在新建工程时自动提示安装对应固件包。如果安装的是老版本，建议先更新工具，再考虑工程。

STM32CubeMX 安装本身没什么难度，但有两个点需要注意。第一，CubeMX 下载固件包时需要联网，并且在首次安装 STM32N6 器件支持时，文件较大，网络不稳定会导致下载失败。国内网络环境下，如果总是下载中断，可以考虑从官网下载离线安装包后手动导入。第二，固件包安装路径不要用中文或带空格的路径，后面生成工程、调用工具链时可能会出现奇怪的路径解析问题。

除了 CubeMX，还需要准备 STM32CubeProgrammer（用来烧录外部 Flash）和至少一款 IDE。我这边用 STM32CubeIDE，因为和 CubeMX 配合最顺，生成工程后直接双击打开。如果你团队习惯用 IAR 或 Keil，CubeMX 也支持生成对应工程，但下面遇到链接脚本问题时，不同 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 mode（XIP 模式），也就是把外部 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 生成出来的是一个安全的工程和一个非安全的工程，两部分通过 SAU（Security 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 生成的是 .icf，MDK 生成的是 .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 port=SWD mode=HOTPLUG -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 文件里 LMA（load memory address）和 VMA（virtual 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 问题速查表

排查这类问题最关键的一点是：一次只改一个变量。我刚做 STM32N6 的时候，遇到复位无反应，同时改了链接脚本、BOOT 引脚和 XSPI 参数，结果烧了一个星期都没找到问题。后来老老实实把 Flash 内容读回来对照，才发现最初 XSPI 的参数就配错了，后面几轮改动都是在错误基础上叠加。

最后分享一个我个人的操作习惯：在 CubeMX 里把 LOAD RUN 相关的配置项写进工程注释，特别是 XSPI 的映射地址、时钟参数、安全区划分这三类信息。这样生成的代码在移交或者保存半年后再回看时，一眼就能回忆起当初的配置意图。另外建议每个里程碑版本保存一份 CubeMX 的 .ioc 文件和对应的链接脚本，回到旧版本定位问题时会非常有用。STM32N6 的 LOAD RUN 工程并不难，难的是把启动路径和存储映射的每个环节都想清楚。按这个流程搭一遍，你就能把精力放到真正有挑战性的业务代码上去了。