做低功耗数据采集产品的时候选型定了 STM32U5G9NJH6Q外挂一片 64MB 的 octal NOR FlashMX25LM51245G当日志存储。方案在板子上跑得倒是挺顺真正折磨人的是生产烧录环节ST-Link 连上芯片STM32CubeProgrammer 里选好外部存储器按下 Start直接给你甩一个错误弹窗。配套的官方教程只能覆盖到官方开发板遇到定制板上的 OCTOSPI 问题网上能直接参考的实战记录很少最后只能靠一条条报错信息去反推。折腾了快两天总算把整套流程跑通。这篇文章就是那两天的完整记录写给同样在 STM32U5 上用 OCTOSPI 外扩 Flash、又在 STM32CubeProgrammer 里卡住的朋友新手可以参考这里面的使用入门路径老手可以直接跳到问题排查章节。1. 先搞清楚 STM32CubeProgrammer 和 OCTOSPI 之间是怎么配合的1.1 External Loader 机制到底是怎么回事STM32CubeProgrammer 本身并不认识任何外部 Flash 芯片。它烧写外部存储器的原理是通过 SWD 调试接口往 MCU 的 RAM 里加载一个叫 External Loader外部加载器的固件然后让这个固件在目标芯片上跑起来再由 CubeProgrammer 通过调试接口给固件下发读、写、擦除命令。这个固件的格式是 .stldrSTM32CubeProgrammer 安装目录下自带一批对应的是各家官方开发板的配置。这个机制设计得很巧妙把“复杂的 Flash 操作”下沉到芯片内部执行上位机只负责发指令和收数据。但它也带来了一个非常现实的问题你在 CubeProgrammer 里选择外部存储器时选的是某一个 .stldr 文件这个文件里的所有配置——GPIO 分配、OCTOSPI 时钟、Flash 型号对应的命令序列——都是按官方板子写死的。你的板子只要有一处和官方板不同loader 初始化 OCTOSPI 的时候就可能直接失败或者初始化成功了但读写的数据是错的。我在 STM32U5G9NJH6Q 上遇到的那些报错根源基本都是这个。注意官方 .stldr 文件位于 STM32CubeProgrammer 安装目录的 bin/ExternalLoader 文件夹下常见默认路径是 C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\ExternalLoader。凡是名称里带 STM32U5G9J-DK1 字样的都是针对官方开发板的定制板只能拿来当参考不能直接复用。1.2 STM32U5 的 OCTOSPI 有什么特殊性STM32U5G9NJH6Q 这颗料主核是 Cortex-M33内部有 4MB Flash、2.5MB SRAM最大的亮点是带两个支持 Octal 的 OCTOSPI 外设可以外挂大容量 NOR Flash 做代码 XIP 或者数据日志存储。和老的 QUADSPI 相比OCTOSPI 支持 1/2/4/8 线宽支持 SDR/DDR 双沿采样还带 DQS 引脚反馈时序上复杂了不少。有两个点特别容易让开发者翻车。第一U5 系列默认开了 TrustZone。OCTOSPI 的寄存器和它用到的 RAM 区域都分 secure / non-secure 属性而 external loader 默认运行在 non-secure 域。如果你的 option bytes 里 TZEN 是打开的loader 要加载的 RAM 区域恰好被划成了 secure那 CubeProgrammer 把 loader 写进内存之后它一执行就崩表现出来就是各种莫名其妙的加载失败。如果产品不需要 TrustZone最省事的做法是直接在 CubeProgrammer 的 Option Bytes 页面里把 TZEN 关掉代价是触发一次整片擦除数据记得提前备份。第二OCTOSPI 的时钟源和分频配置比较讲究。U5 的 OCTOSPI 内核时钟可以从 PLL1Q、HCLK 等多个来源取具体走哪条路径看 RCC 配置。如果 PLL 没配好OCTOSPI 时钟可能超出 Flash 支持的范围。很多 8 线 Flash 标称支持 200MHz但在 1.8V VCC 下实际时序余量没你想的那么大所以先把频率降下来跑通再考虑拉高频。还有一个容易被忽略的点U5G9NJH6Q 是 TQFP216 封装IO 非常多但每个引脚的 AF复用功能映射和官方开发板并不完全一致。官方 loader 用的那几个 GPIO在你的板子上可能是别的功能、甚至没引出来。所以拿到一块定制板的第一步永远是核对原理图里 OCTOSPI 总线的实际走线再去数据手册的 AF 映射表里查对应关系不要想当然。2. 我在 STM32U5G9NJH6Q 上踩过的三类典型问题2.1 连接阶段就失败No STM32 target found第一次拿到新板子接上 ST-Link打开 STM32CubeProgrammer点连接弹出来 No STM32 target found。这种问题我见过太多次按下面的顺序排查基本能覆盖 90% 的情况。首先看 NRST 有没有接到 ST-Link 的 NRST 脚。CubeProgrammer 左侧设置里有 Connect under reset 选项勾上之后调试器会在复位状态下建立连接。如果用户代码里已经把 PA13/PA14SWDIO/SWCLK复用成普通 GPIO 了用这种方式才能连上。前提是 NRST 必须连到调试器否则无法控制复位时序。其次查 option bytes。如果之前烧过 RDP读保护等级RDP 不是 Level 0调试口会被锁掉。RDP Level 1 还能靠 connect under reset 连上但无法读写Level 2 就直接永久锁死只能换芯片。排查方法连接失败时切到 Option Bytes 页看能不能读出来。如果读出来发现 RDP 是 Level 1 或 Level 2先把读保护降级再继续操作。还有一个很少被注意的点U5 有多路电源域。VDD 要供电、VDDA 模拟电源也要还有 VDDUSB、VDDIO2 这些独立电源域。如果某一脚没上电芯片可能进入异常状态。同时 ST-Link 的 VTREF 参考电压要和板子的 VDD 一致否则电平不匹配也会连接失败。我当时实际的处理是把 NRST 连线补上勾选 connect under reset问题立刻解决。后来才发现这块板子之前跑测试程序时把 SWD 引脚占用了新程序里没来得及改回 AF 功能导致第二次连接失败。这个坑非常典型尤其是量产返修板十有八九是这个问题。2.2 能连上芯片但选择外部存储器时报错External loader not found / Init error连接芯片这一步过了接下来在外部存储器下拉框里选择工作区会遇到两类报错。第一类是 External loader not found。说明 bin/ExternalLoader 目录下没有匹配的 .stldr 文件。要确认你选的存储区比如 OCTOSPI1 起始地址 0x90000000对应的 loader 是否存在。如果板子是定制的八成没有现成 loader只能自己写后面第 3 节会详述。第二类是 Init error 或 Read error。说明 loader 文件加载成功了但 loader 里的 Init() 函数返回失败。Init() 做的工作通常包括初始化 OCTOSPI GPIO、配置 OCTOSPI 控制器、向 Flash 发读 ID 命令、比对 ID 是否正确。任何一步失败都会导致加载器初始化失败。这里给一个特别管用的排查手段不要靠瞎猜先用一个最小的 STM32 测试工程直接用 OCTOSPI 的 SDR 模式、标准 SPI 命令比如 0x9F 读 JEDEC ID把 Flash 的 ID 读出来。如果读得出来说明硬件链路供电、IO、时钟、Flash 本身都是通的问题就在 loader 的配置。如果读不出来先查硬件Flash 的 VCC 供电、WP 引脚是不是被拉低、CS 上拉是否正常。这个“先读 ID”的习惯能省掉大量无效时间。我当时调试的时候loader 里怎么配都报 Init error后来一查发现是 Flash 的 VCC 标称 1.8V而板子上的 LDO 坏了实际电压只有 1.2VFlash 根本没法工作。这属于硬件问题软件配置再对也白搭。2.3 擦除、编程或校验阶段报错Memory programming error / Data mismatch能初始化、能读数据但一擦除一写入就报错或者校验不通过。这类问题是 OCTOSPI 场景里最磨人的我把它拆成三个最常见的根因。第一个是 DDR 模式配置问题。8 线 NOR Flash 普遍支持 DDRDTR双沿传输时序参数非常敏感。loader 里开了 DDR但 DQS 反馈信号没接或者 DQS 时序配置不对写入的数据就会错位。校验的时候报的地址通常在 0x90000000 附近和数据偏移量相关看起来很随机。最粗暴有效的方法先把 loader 改成 SDR 模式跑通再回头调 DDR。不要一上来就追求高性能先把链路打通。第二个是写保护没解锁。很多 NOR Flash 上电后默认开启写保护需要发 Write Enable0x06才能擦写。如果 loader 的 Write 和 SectorErase 流程里没有先发写使能命令擦除可能静默失败或者编程时写进去的依然是 0xFF。这个问题很隐蔽因为报错不一定出现但数据校验会失败。第三个是时钟频率过高。前面说过1.8V 供电下 Flash 的实际频率上限会降低。如果 loader 里配置的 OCTOSPI 时钟是 100MHz但 Flash 在这个电压下只能稳定跑 66MHz就会出现偶发性错误。错误可能不是每次都出现而是在某个地址段反复失败。生产线上这种“一会儿好一会儿坏”的问题最可怕直接把频率降到标称值的 50% 再试。心得OCTOSPI 相关问题调试优先级永远是先 READ 后 WRITE先 SDR 后 DDR先低频后高频。按这个顺序能把变量的维度从 5 个降到 1 个排查效率提升非常明显。3. 从零适配一块板载 OCTOSPI Flash 的完整记录3.1 用 STM32CubeMX 生成 External Loader 基础工程如果你的板子没有现成 loader就得自己写一个。ST 的 STM32CubeU5 固件包里通常自带 External Loader 的参考工程位置一般在 Projects/STM32U5G9J-DK1/Applications/ExternalLoader 下不同版本固件包路径略有差异。先把它拷贝出来作为蓝本。这个工程的核心是几个函数签名由 STM32CubeProgrammer 的加载器协议固定int Init(void); // 初始化 OCTOSPI 和 Flash 芯片 uint32_t Read(uint32_t Address, uint32_t Size, uint8_t *Buffer); // 读数据 uint32_t Write(uint32_t Address, uint32_t Size, uint8_t *Buffer); // 页编程 uint32_t SectorErase(uint32_t StartAddress, uint32_t Size); // 扇区擦除 uint32_t MassErase(void); // 全片擦除还有一个描述 Flash 特性的结构体CubeProgrammer 会用它来规划整个地址空间和操作粒度const LoaderS Loader { MY_BOARD_OCTOSPI_MX25LM51245G, // loader 名称会显示在 CubeProgrammer 下拉框里 0x90000000UL, // 外部存储器起始地址 0x04000000UL, // 存储器容量64MB 0x00000100UL, // 编程页大小256 字节 0x00001000UL, // 擦除块大小4KB ... Init, Read, Write, SectorErase, MassErase, };生成工程后第一件事是核对芯片型号和 RAM 起始地址。STM32U5 的 SRAM 在 TZEN 打开时loader 需要放在 non-secure 可访问的区域典型地址是 0x30000000 起的 non-secure alias。如果 TZEN 关闭直接用 0x20000000 这个常规区域就行。另外CubeProgrammer 对 loader 的 API 版本有检查如果提示 Old API version多半是你 loader 工程里的 STM32_ExternalLoader.h 头文件版本和当前 CubeProgrammer 不匹配去固件包里找对应版本替换即可。3.2 修改 GPIO、时钟和 Flash 命令配置工程生成好之后重点改三块配置。第一块是 GPIO。打开 STM32U5G9NJH6Q 的数据手册找到 OCTOSPI1 的 Alternate Function 映射表对照你的原理图把 IO0~IO7、CLK、CS、DQS 对应的 GPIO 引脚和 AF 号全部填到 CubeMX 里。每个 IO 都要配置成高速 push-pull上下拉状态按 Flash 手册要求设置一般是默认带上拉更稳。这里特别提醒一句网上很多教程直接抄官方板子的引脚放到自己的板子上未必成立务必以自己原理图和 AF 表为准。第二块是时钟。OCTOSPI 内核时钟建议先从 PLL1Q 取频率先设保守一点比如 50MHz。等整条链路跑通了再根据 Flash
