拿到一块STM32MP235的核心板接上电源串口线连好波特率设置成115200打开终端上电——终端里一片空白。这就是“STM32MP235 fails to boot”最经典的开场白。STM32MP235是ST第二代MPU产品线里的一员基于Arm Cortex-A35应用处理器和Cortex-M33实时内核的异构架构面向工业网关、智能显示、物联网边缘设备这些场景。和第一代STM32MP1系列相比它在安全启动、电源管理、外设隔离上做了不少强化但也正因为这些强化启动链路变得更长排查启动失败的复杂度也跟着上来了。这篇文章围绕我实际调试STM32MP235启动失败的过程把从硬件检查到软件配置的完整排查思路拆开讲清楚给正在被这块芯片折腾的工程师一点参考。1. 启动失败先别慌把STM32MP235的启动链路拆开看STM32MP235这类MPU的启动过程和单片机完全是两码事。玩过STM32单片机的朋友都知道上电之后从Flash的某个固定地址开始执行指令搞个Bootloader也无非是IAP跳转。但到了MPU这一级芯片内部没有大容量的可执行Flash程序运行所依赖的外部DDR内存颗粒在上电的瞬间也还没有完成初始化CPU连代码都没地方放所以必须有一个分阶段加载的过程。1.1 BootROM这一步到底干了什么芯片出厂时固化了一段不可修改的BootROM代码上电后CPU的第一条指令就从BootROM开始执行。BootROM的任务是先把最小系统跑起来——内核时钟、基础电源域、启动介质对应的接口控制器——然后根据BOOT引脚的组合电平或者OTP区域里烧写的配置从SD卡、eMMC、NOR Flash、NAND Flash、USB、UART这些介质中选择一个启动源把第一级引导程序FSBLFirst Stage Boot Loader加载到芯片内部的SRAM里再跳转过去执行。这里有一个很多人第一次接触时会踩的坑BootROM不像PC的BIOS那样去理解分区表更不会去FAT32文件系统里寻找什么引导文件它是直接到固定偏移地址去读取原始二进制镜像的。你随手拿一张SD卡格式化成FAT32把编译好的TF-A镜像文件复制进去插到板子上结果一定是什么反应都没有。BootROM要的是镜像被烧写到特定扇区偏移处的原始数据这个细节后面我会用一整章展开讲。1.2 TF-A、OP-TEE、U-Boot、内核谁接谁的班FSBL在ST的官方方案里通常就是Arm Trusted Firmware-ATF-A。TF-A运行后先初始化外部DDR内存控制器配置电源管理把外设需要的时钟补齐然后从同一个启动介质里加载FIPFirmware Image Package镜像包。FIP里打包了OP-TEEBL32和U-BootBL33这两个后续阶段的镜像。OP-TEE负责提供安全世界运行环境U-Boot作为第二级引导程序初始化设备树、外设、网络、显示这些硬件功能设置bootargs最后把Linux内核加载进内存并跳转执行。你可以把这条链路理解成接力赛BootROM把第一棒交给TF-ATF-A把第二棒交给FIP里的OP-TEE和U-BootU-Boot再交给内核。每一棒都有自己明确的职责边界和日志输出链条上任何一棒出了问题表现就是系统死在那个阶段并打印对应的错误日志——或者干脆连日志都没有。1.3 用串口日志判断“死在哪个环节”排查boot失败的第一步永远是先看日志停在哪个阶段。我当时调试这块板卡串口终端上最后一行打到了TF-A的DDR初始化相关输出之后就再无动静那基本可以把问题锁定在DDR配置或者后续FIP加载上。如果日志连TF-A的版本信息都没打出来问题大概率在更前面要么BootROM没找到有效的FSBL镜像要么FSBL在加载阶段就被硬件问题卡住了。我习惯把日志分成几个区间来看完全静默、只能看到BootROM早期输出、TF-A开始打印、U-Boot开始打印、内核早期打印。每个区间对应不同的排查方向。用日志分段定位的方法比闷头去翻原理图高效得多也更容易向同事或者原厂FAE描述问题现状。2. 上电后完全没反应硬件层面的排查顺序如果遇到的是完全没有任何串口输出的情况不要急着怀疑软件配置先老老实实回到硬件上查。嵌入式调试里相当大比例的“完全不启动”都是由硬件层面的小问题引起的而且这些问题往往发生在你意想不到的地方。2.1 电源轨和时序先从万用表量起STM32MP235这种MPU的电源轨数量远超单片机核心供电、DDR供电、IO供电、模拟供电经常是分开的独立电源轨。上电之后第一件事拿万用表逐路测量各路电压是否正常特别是DDR供电和核心电压。我遇到过一块板子核心电压纹波偏大常温下一切正常温度一上来就启动失败最后用示波器盯DDR电源的纹波才发现是滤波电容位置不对导致的。比电压数值更隐蔽的是电源时序问题。MPU通常要求各路电源按特定顺序上电比如先给VDD再给核心电压如果电源管理芯片的配置不对就会出现上电顺序颠倒。这种问题在厂商做好的核心板上很少见但在自己画板子的时候是高发区。排查的时候拿示波器同时测几路电源的上电波形和复位信号释放点和参考手册里的时序图逐项对照基本能确认是不是时序问题。2.2 BOOT引脚拨码开发板上的“启动源选择开关”很多开发板或者核心板上会有一组拨码开关或者跳线用来选择启动源。STM32MP235和MP1系列类似通过BOOT引脚的组合电平来确定是从SD卡、eMMC、USB、UART还是其他介质启动。我犯过一个特别低级的错误为了用STM32CubeProgrammer烧录镜像把启动模式切到了USB烧完之后忘了拨回SD卡启动上电当然起不来串口一点输出都没有。排查了半天最后发现只是拨码开关没拨回去。这个事听起来蠢但实际工程中真的很容易发生因为你永远不知道上一手调试的人把开关留在了什么位置。所以第一步应该做的是对照板子原理图确认当前BOOT引脚电平对应的实际启动源同时明确测试目标——我们到底想让板子从哪个介质启动。调试排障期间每次上电之前都确认一下启动模式拨码的实际档位这个习惯能替你省下大量的无效排查时间。2.3 时钟与复位HSE晶振和NRST的隐蔽问题MPU启动依赖外部高速时钟HSEBootROM要起内部PLL时钟源如果没起振后面全免谈。我见过一个案例晶振虚焊示波器点上没有波形BootROM把时钟配置成错误状态系统直接卡死。对于量产板贴片晶振的匹配电容值不对也会导致起振困难或者频率偏差这些问题在低温环境下表现更明显。复位信号同样值得关注。正常情况下上电时NRST引脚应该有一次拉低再释放的过程用示波器抓一下如果复位引脚一直被钳在低电平说明外部复位电路异常或者有看门狗在反复复位芯片。反复复位这种情况很有迷惑性从日志上看像是“每次都启动到同一个位置就死了”实际上是芯片被复位打断又重新启动形成了循环。遇到日志反复重演的情况记得先确认复位信号有没有问题。2.4 调试串口型号与电平日志没出来之前先确认通道串口是MPU调试最重要的通道但很多人栽在串口本身。首先确认调试串口用的是哪一组UARTSTM32MP235的官方开发板一般会把调试串口引到固定的引脚上但你自己设计的板子可能完全不同必须看原理图确认。其次确认电平板上是否有USB转串口芯片还是直接引出的TTL电平两种情况接线方式完全不同。再有就是波特率常见的是115200 8N1但有些板子在引导阶段可能用更低速率或者引导程序和内核阶段使用不同波特率遇到日志中断可以试着换几个波特率看看。我当时调试的时候一度以为板子完全没启动后来发现是USB转串口线坏了换了一根线马上有日志输出。排查的第一步永远是把串口通道验证好——可以把串口的TX和RX短接做自发自收测试确认通路没问题再往下查设备。3. 有日志但卡在初始化FSBL与信任链的定位方法硬件排查是“外功”FSBL及后续阶段的日志分析就是“内功”。接下来专门讲有日志输出但系统初始化不通过的情况这种情况在启动失败里占比最高因为硬件问题往往比较直观而启动链路各阶段的配置问题则需要结合日志逐层定位。3.1 日志卡在哪个函数问题就锁定在哪个模块TF-A启动过程中会在串口输出一系列NOTICE和ERROR信息。比如初始化DDR之前会有对应的内存检测日志加载FIP之前会有介质读取的信息。如果你的日志停在了DDR初始化相关的位置那就应该把目光集中在DDR这一块而不是跑到U-Boot的配置里去找原因。我当时调试手头这块STM32MP235板卡时日志停在了TF-A BL2阶段的早期大概是在初始化DDR的地方。TF-A打印了DDR初始化相关的信息但后续没有出现正常的FIP加载输出。这说明TF-A认为DDR初始化失败了或者初始化之后回读校验不过。这类问题多半和DDR颗粒型号、DDR初始化参数、PCB布线质量有关。3.2 DDR初始化失败的典型日志和排查DDR初始化是整个启动链路中最容易出问题的环节之一。MPU的外部DRAM不是插上就能用的要根据颗粒型号、容量、位宽、时序参数做一整套寄存器配置。TF-A里编译进去的DDR配置如果和实际颗粒不匹配轻则初始化失败重则初始化流程能过但系统一跑就随机死机。典型的日志长这样NOTICE: BL2: v2.10-stm32mp2-r1 (stm32mp235) NOTICE: BL2: Built : 09:30:00, May 20 2025 NOTICE: BL2: DDR memory init... ERROR: DDR memory configuration failed排查DDR问题时先核对板子上实际使用的DDR颗粒和参考设计是否一致再核对TF-A里对应DDR初始化文件中的参数容量、位宽、频率、时序参数。STM32CubeMX在生成工程时会根据选择的板卡自动带入DDR配置但如果核心板是你自己设计的这部分必须认真手工核对尤其是PHY校准相关的参数很容易因为PCB走线的细微差异导致失败。3.3 签名与OTPMP2新增的安全约束STM32MP2系列比MP1在安全启动上强化了不少。如果OTP区域已经烧写了强制安全启动的配置那么BootROM只会加载带有效签名的FSBL任何未签名或者签名校验失败的镜像都会直接拒绝启动。这类问题的特征很明显BootROM可能有打印TF-A完全不出现或者TF-A打印了签名校验失败的ERROR信息。排查时先确认当前芯片的OTP配置状态STM32CubeProgrammer可以读取OTP。开发阶段如果不是在联调安全启动我建议不要把OTP的安全启动使能位提前烧进去。一旦烧进去之后每次调试都要面对镜像签名问题严重拖慢开发节奏。而且OTP是一次性可编程的烧错了不能改回来这个教训在很多项目里都出现过。3.4 用STM32CubeMX重建FSBL和FIP当FSBL相关配置可疑时重建一套干净的FSBL和FIP通常比在旧配置上猜来猜去更高效。STM32CubeMX支持为STM32MP2系列生成TF-A、OP-TEE、U-Boot的整套工程模板生成之后编译产出TF-A二进制、FIP镜像再用ST官方工具烧进启动介质。这一步的关键是选对CubeMX版本和固件包版本。某些早期的MP2固件包存在已知的启动问题升级到最新版可能就解决了。我遇到过一次情况用老版本固件包生成的TF-A在MP235上启动时挂掉换成新版本固件包重新生成后一次通过。ST在MP2系列上的迭代很快保持工具链和固件包更新是降低启动排障成本的重要一环。4. 启动源和烧录镜像SD卡、eMMC的分区与偏移真相有日志、硬件也没问题但系统就是起不来这时候十有八九是启动介质里的镜像布局不对。这节专门讲SD卡、eMMC这类启动介质的分区布局和烧录细节也是STM32MP235启动失败里最容易忽略的一块。4.1 BootROM找镜像不看分区表只看偏移这是嵌入式MPU和PC最大的不同。PC的UEFI固件会去扫描GPT分区表里的ESP分区寻找bootloader文件而STM32MP235的BootROM不会解析任何复杂的文件系统它是直接寻址读取SD卡或eMMC上某个固定偏移处的原始二进制数据。以STM32MP1系列为参考FSBL镜像位于SD卡的某个固定扇区偏移随后紧跟的是FIP镜像位置。MP2系列的具体偏移以官方参考手册为准不同系列、不同版本之间可能有差异。很多人第一次接触时把SD卡插到电脑上格式化成FAT32把TF-A和FIP文件拷贝进去再把SD卡插回板子然后发现启动失败——原因就是BootROM根本不认识FAT32文件系统里的文件它只去固定位置找原始数据。想验证很简单用十六进制工具直接查看SD卡对应偏移区间的数据如果看到的不是二进制镜像内容而是一堆FAT文件系统标记说明镜像根本没写对地方。4.2 用STM32CubeProgrammer安全的烧录流程STM32CubeProgrammer是ST官方的烧录工具也是处理STM32MP235启动失败时绕不开的利器。它可以烧写SD卡、eMMC、NOR等启动介质也可以操作OTP、读取芯片信息。标准烧录流程大致是准备好一个包含flashlayout文件的工程目录flashlayout里定义了FSBL、FIP等镜像要写到哪些偏移位置把目标板BOOT拨码切到USB启动或UART/ST-LINK模式取决于开发板设计用USB线连接PC和目标板在STM32CubeProgrammer里选择对应接口和配置文件执行下载。烧录完成后把拨码切回正常启动源复位板子。这里容易被忽略的细节是外部加载器External Loader的选择。如果板子上用的是eMMC需要选择对应的eMMC加载器文件如果加载器选错烧录工具可能无法正确识别存储介质或者烧录进去之后BootROM依然无法正常读取。4.3 PC的“no boot device”和MPU的“启动失败”其实是一回事前面提到的“no boot device found.press any key to reboot the machine”这类PC启动报错在MPU世界里对应的就是BootROM把可用的启动源都尝试了一遍但没找到有效的FSBL镜像。PC上会给出明确的英文提示而STM32MP235的BootROM通常不会输出这么人性化的话往往就是安静地失败。理解这一点对调试很有帮助如果你把启动介质拔掉或者介质里FSBL偏移处是空的板子就处于这种“找不到启动设备”的状态。所以当板子完全静默无日志时先假设它处于这种状态然后检查镜像是否真的被写进了正确的介质偏移位置比反复怀疑硬件更有效。4.4 烧录后第一次启动失败的常见原因烧录流程本身显示成功但启动还是失败这种情况也经常遇到。我总结过几个高频原因第一烧录时选择了错误的flashlayout文件或加载器导致FSBL实际被写到了错误偏移第二烧录后启动模式拨码没有切回正确的启动源第三镜像和芯片型号不匹配比如用了STM32MP1系列或者其他型号的FSBL去启动MP235相互之间不兼容第四eMMC或SD卡的接口电压配置与BootROM的默认配置不一致导致BootROM无法稳定读取介质。这些问题的共同特征在于烧录工具显示编程完成但启动日志完全静默或者只有极少输出。遇到这种情况先不要反复烧录停下来核对三件事镜像对不对、偏移对不对、启动源对不对。5. 我总结的快速定位清单与避坑经验前面几章把STM32MP235启动失败的主要排查方向都过了一遍最后这部分是我个人的总结整理成了一套可以直接照着做的排查清单以及一些容易踩的坑。5.1 五分钟快速定位法确认调试串口通道本身是通的线缆、电平、波特率都检查一遍确认启动模式拨码或OTP选中的启动源和预期一致上电观察是否有任何串口输出完全没有输出就先测电源、时钟、复位有早期输出但卡住把日志定格对照TF-A各阶段标志信息确认卡点卡在镜像加载相关阶段用STM32CubeProgrammer重新烧录正确偏移的镜像烧录后仍失败换一套干净的STM32CubeMX生成工程排除配置污染。这套顺序基本覆盖了从硬件到软件的完整排查链路按序执行能在短时间内把问题范围缩小到具体模块。5.2 容易被忽略的细节有几个细节是踩过坑之后才格外注意的列出来给大家提个醒开发板自带的SD卡可能已经烧录过一套旧镜像直接使用前先确认镜像版本是否匹配当前板卡某些核心板是通过电阻配置BOOT引脚而不是拨码开关换板子时一定要重新看原理图STM32MP2系列的电源域划分比MP1更细如果软件里配置了不支持的电源状态启动可能卡在电源管理初始化串口调试默认波特率各阶段可能不同某些情况下需要尝试多个波特率才能看到完整日志OTP配置是不可逆的开发阶段不要随意烧OTP尤其是安全相关选项。5.3 资料查找路线与参考手册用法STM32MP235的资料查找我推荐优先看ST官方的Reference Manual中的Boot章节、STM32CubeMP2固件包里的Docs目录以及ST官方Wiki。很多启动问题在官方Wiki上能找到对应的说明或已知问题记录。另外ST在Github上的tf-a、u-boot仓库的commit记录里也经常能翻到针对特定启动问题的修复值得花时间搜一搜。最后说一个我在实际调试中的体会遇到启动失败不要急着怀疑芯片坏了。STM32MP235这种复杂度远超单片机的平台启动失败几乎总是由可复现的配置问题引起的。按照“串口通道 → 启动源 → 电源时钟复位 → 镜像偏移 → 信任链 → DDR配置”这样的顺序来排查绝大多数问题都能在半小时内定位到真正的根因。我当时那块板子最后查出来就是FIP镜像里打包的U-Boot版本和TF-A版本不匹配导致启动链在传递环节崩溃重新生成一套版本匹配的镜像组合之后一切恢复正常。