1. 问题现象：BootFailed没等到，UART5_TX上来了个方波
拿到STM32N6570-DK这块板子，按资料把BOOT拨码开关拨到UART启动位置，打算通过UART5的引导通道看看BootROM输出了什么。按照文档，PG10对应UART5_TX，接上示波器，上电，预期的是115200 8-N-1的打印信息。结果屏幕上一片方波，频率稳定在4.3MHz左右，占了满屏，压根没有数据帧的影子。
这种"对着文档做，但结果完全不在预料之内"的情况，在嵌入式开发中太常见了。尤其STM32N6570这种新平台，资料相对少，遇到问题的时候容易卡住。我一开始也怀疑是不是自己接线问题，后来仔细量了一下，确认信号来自PG10引脚本身，不是测量误差，也不是探头接触不良。这时候我意识到，问题出在更底层的地方：要么MCU根本没进入预期的启动模式，要么引脚被初始化成了其他外设功能。
接下来要做的是系统化排查。先别急着改代码，把现象拆解清楚：一是为什么没有BootFailed输出，二是这个4.3MHz方波到底从哪来的。这两个问题看似独立，实际上指向同一个核心——MCU启动路径和引脚复用配置。搞清楚这条链路，问题就解开了一半。
1.1 先确认波形特征：是噪声、方波还是UART数据
示波器第一次捕捉到信号时，我做了几个关键检查。首先是频率稳定性，观察了大约10秒，频率没有漂移，始终稳定在4.302MHz左右，占空比接近50%。这个特征非常关键：UART空闲电平是高，起始位是低，一帧数据里高低电平的时间分布并不均匀，绝不会出现规则的50%占空比方波。所以基本可以断定，这不是UART数据。
其次我检查了信号幅度。PG10上的方波幅度大约3.3V，也就是0至VDD之间摆动。如果是外部噪声耦合，幅度通常不稳定或者偏小；3.3V的逻辑摆幅说明这是一个真实的驱动信号——MCU内部有某个外设正强驱动这个引脚。这也排除了浮空引脚受到干扰的可能。
最后，我尝试改变示波器触发方式，从上升沿触发改成下降沿，频率读数不变。说明这是一个持续输出的周期性信号，不是启动时的一次性脉冲。结合这些特征，我心里大概有了方向：要么是某个时钟输出，要么是定时器PWM，反正不是UART该有的样子。
提示：115200波特率下单个位宽约8.68微秒，对应的数据翻转频率大约是115kHz这个量级，就算发送0x55这种连续翻转的数据，也离4.3MHz差了好几十倍。所以从频率上就能一票否决"这是UART信号"的可能性。
1.2 为什么"预期输出"和"实际波形"差距这么大
在STM32N6570-DK上，BootROM的UART引导通道按参考手册应当使用UART5，TX引脚就是PG10。预期流程是：上电复位→BootROM检查启动模式→进入UART引导模式→在UART5上输出"BootFailed"或者其他提示信息。这里有个容易忽略的细节：BootROM只有在上电时检测到BOOT引脚处于特定电平组合时，才会进入UART引导模式。
如果BOOT引脚没有被正确设置为UART启动模式，BootROM会直接跳到主Flash去执行用户代码。而如果用户Flash里烧录了一个把PG10初始化成PWM输出的程序，那么上电后这个引脚自然输出方波，跟BootROM一点关系都没有。这就是"预期BootFailed，实际看到方波"的最常见解释。后面的一系列排查，都是围绕这个判断展开的。
2. 启动流程与BootROM的UART行为
要解决这个问题，首先得把STM32N6570的启动机制搞明白。这个系列基于Arm Cortex-M55内核，主频最高800MHz，还集成了NPU，定位是边缘AI和视觉处理。它的BootROM和传统STM32有很多相似之处，但又多了一些新东西。比如启动源更多、BootROM中包含更多底层初始化逻辑，并且对供电时序和外设状态有更严格的要求。
STM32N6570的启动流程大致如下：复位后，CPU从固定地址取第一条指令，这是BootROM代码。BootROM首先做基本的时钟初始化，比如使能HSE、缓存以及供电管理。然后读取BOOT引脚的电平组合，判断启动目标。可选启动源包括主Flash、UART、USB、SPI以及FDCAN等。如果用户代码在Flash中且有效，BootROM会跳转到用户程序入口；如果没有有效用户程序或者Boot引脚选择了外设启动，则会进入对应的引导协议。
2.1 BootROM什么时候会输出"BootFailed"
很多STM32开发者都知道，BootROM的UART引导模式会输出BootLoader命令提示符（比如"C"字符循环），但较少有人关心"BootFailed"这类字符串什么时候出现。实际上，这个字符串通常表示BootROM在尝试引导过程中发现了异常。比如下载的数据校验失败、地址超出范围，或者Flash操作出错等。
在ST官方BootROM代码中，BootROM会通过UART发送错误码，不同错误码对应不同含义。如果你在某个引脚上期待看到"BootFailed"，意味着你已经确认BootROM确实进入了UART引导模式，只是后续某个步骤出错了。这里的关键点是：BootROM必须先进入UART模式，才会初始化UART5并输出调试信息。如果BootROM压根没进这个模式，那引脚上就不会有任何UART数据。
结合前面看到的现象——4.3MHz方波而不是UART数据——可以初步推断：BootROM很可能根本没进入UART引导状态。因为一旦BootROM初始化UART5为TX功能，PG10的电平在空闲时应该保持高，不会产生持续方波。所以第一步要查的是启动模式选择。
2.2 UART启动模式的进入条件与引脚配置
STM32N6570的BOOT引脚具体是哪些，必须查对应型号的数据手册和参考手册。在N6570-DK开发板上，通常有一个拨码开关或者跳线专门用于选择启动源。手册上会写明：某个位置对应UART启动，某个位置对应Flash启动，某个位置对应USB启动。这里要特别提醒：不要只看拨码开关的位置标注，还要用万用表确认引脚上的实际电平。
原因在于，开发板上的拨码开关可能连接了额外的上拉或下拉电阻，或者和其他外设共用了引脚，导致电平组合不符合预期。我就遇到过板载拨码开关丝印标的是"UART"，但由于相邻引脚短路，实际电平组合却进入了USB模式的情况。所以，测量BOOT引脚电平是排查的第一步，也是成本最低的一步。
进入UART引导模式后，BootROM会初始化UART5，波特率是固定的115200，8位数据、无校验、1位停止位。TX引脚是PG10这一点，在多个资料中一致，但也需要确认开发板的原理图，因为有些评估板会通过跳线或者0欧电阻把UART重映射到其他引脚。在STM32N6570-DK上，PG10直连排针，没有经过额外电路，所以测量点没有问题。
2.3 BootROM UART交互协议细节
一旦BootROM准备好UART引导，它会开始周期性发送同步字符。以常见STM32 BootROM为例，上位机（比如STM32CubeProgrammer）和BootROM之间有一个握手机制：BootROM发送一个同步字节，上位机回复应答，两者确认波特率和参数一致后，才进入正式的擦写流程。
这里有个实战经验：用串口助手直接看BootROM输出时，可能看到的是"BootFailed"或者一串"CCCCC..."。如果是"CCCCC..."，说明BootROM在等待上位机同步；如果收到"BootFailed"，说明同步或者下载过程出了异常。但如果你在PG10上测到的是方波，那这两者都不是，说明BootROM压根没有运行UART引导代码，问题在更前面的环节。
3. 4.3MHz方波的来源推断
方波频率4.3MHz，这是一个非常有价值的信息。嵌入式系统里，周期信号大多来自时钟分频或者定时器输出。只要我们把系统的时钟树理一遍，再结合引脚复用功能表，就能锁定候选源。
先看时钟树。STM32N6570主频800MHz，内部总线和外设时钟会经过多级分频。芯片内部有几个主要时钟源：HSE（外部高速晶体）、HSI（内部高速RC）、CSI（内部慢速RC）等。如果某个时钟信号通过MCO引脚输出，或者被接到内部定时器时钟输入端，经过分频后就可能产生特定频率的信号。
再看定时器PWM。芯片上的高级定时器和通用定时器都可以输出PWM，频率由定时器时钟和预分频器、自动重装载值决定。如果用户代码把PG10配置成了某个定时器的通道输出，那么输出的PWM频率可以根据配置算出来。但这里的4.3MHz不是整数分频常见的频率值，所以我怀疑它是某种时钟源直接分频的结果，而不是特意配置的PWM频率。
3.1 从频率值反推时钟链路
假设系统时钟是800MHz，逐级分频后得到4.3MHz，这意味着分频系数约为186。800MHz除以186大约是4.301MHz，非常接近实测的4.302MHz。如果系统时钟不是精确800MHz，而是由HSE经过PLL得到的，实际频率可能有微小偏差，这正好解释为什么方波不是恰好4.300000MHz，而是4.302MHz。
另一种可能是内部HSI分频。如果HSI频率是64MHz，64除以15大约是4.267MHz，虽然接近但不完全吻合。如果是128MHz除以30，得到4.267MHz，也不完全吻合。从这些计算看，更可能是PLL产生的某个高频时钟，经过一个非整数分频链路，最终落在4.3MHz附近。
还有一条路：外部晶振。如果板上HSE是25MHz，25除以5.8不是整数，不太可能。如果是24MHz，24除以5.6也不是整数。这些都比较牵强。所以最合理的方向是：某个外设时钟（可能是定时器时钟、MCO时钟输出）被输出到了PG10。
3.2 谁在驱动PG10：复用功能逐一排查
要确定谁在驱动PG10，得查芯片的数据手册里GPIO复用功能表。PG10可以复用为UART5_TX，这是已知的；但它还可以复用为其他功能，比如定时器PWM输出、串行外设接口的信号线、甚至某些调试接口。排查的时候，第一步是读取GPIO复用寄存器，确认当前AF值是什么。
在没有调试器的情况下，也可以用逻辑分析仪抓取启动瞬间的电平变化。如果方波在复位后的极短时间内就出现，那说明是BootROM自己配置的；如果方波在几百毫秒后才出现，那大概率是用户代码在main函数里配置的。两种情况的处理方式完全不同。这个方法在实战中非常有用，因为很多启动问题就藏在"时间窗口"里。
我用示波器的单次触发模式捕获了上电瞬间的波形：从VDD上升到方波出现，间隔大约180ms。这个时间比较长，不像BootROM的快速初始化，更像用户代码里等待时钟稳定之后的外设配置。这进一步印证了"用户的固件在运行，并且把PG10配置成了PWM输出"这一假设。
3.3 用示波器单次触发捕捉启动时序
这个操作值得单独说一下。把示波器通道1接PG10，通道2接3.3V电源（或者使用示波器的电源触发功能），触发方式设置为下降沿，时基调到50ms/div或者100ms/div，然后给板子上电。这样你能同时看到电源建立过程和PG10信号出现的时间点。
我测到的结果非常清晰：电源稳定后约180ms，PG10上开始出现方波，而且一开始就是完整频率的方波，没有频率爬升的过程。这说明外设配置是代码里预设好的，不是启动过程中动态调整的结果。同时，在方波出现前的180ms内，PG10保持高电平，而不是低电平——这一点也很重要，如果PG10在BootROM阶段被配置为UART_TX，空闲时会保持高电平，与观察到的一致。但因为后面变成了方波，说明BootROM阶段结束后，用户代码接管并重新配置了这个引脚。
4. 完整排查实录：从硬件到软件，从静态到动态
明确了方向后，我开始按顺序排查。整体思路是"先硬件后软件、先静态后动态"：先确认板级硬件是否正确，再检查BootROM行为，最后看用户固件是否干扰了引脚功能。每一步都要有明确结论，不能跳过。
硬件层面，我分别检查了电源、BOOT引脚电平、PG10的物理连接以及ST-LINK的连接状态。软件层面，我检查了固件是否烧录到了正确位置、CubeMX生成的初始化代码是否正确配置了引脚，以及是否有调试器影响了启动流程。这一套走下来，整个问题的轮廓就非常清晰了。
4.1 硬件层面：电源、BOOT引脚与PG10物理连接
先看电源。STM32N6570有多个电源域，内核电压、IO电压、SRAM电压都需要在BootROM初始化前稳定。板上电源指示灯正常点亮，测量3.3V和1.8V输出都正常，排除了供电异常。如果供电有问题，BootROM可能连UART初始化都完不成，但通常也不会有稳定的方波输出。
再看BOOT引脚。我找到开发板原理图上与启动模式相关的拨码开关SW1，用万用表测量了对应BOOT引脚的电压。与预期UART启动的组合对比后发现，其中一个引脚的逻辑电平不对，导致实际组合落到了"主Flash启动"。这就是Root Cause的第一步：启动模式根本没选对。
最后看PG10物理连接。查原理图确认PG10是否直接连接到排针，或者中间有串联电阻、跳线、电平转换器。如果板上某个外设（比如音频Codec、LCD接口）也连接到PG10，就会存在信号冲突。我对照原理图，PG10在N6570-DK上直接连到了排针，没有额外外设，可以排除物理冲突。
4.2 检查BootROM行为和Flash中是否已有固件
确定了BOOT引脚电平不对后，我又读了STM32N6570-DK板载Flash的状态。理论上，如果Flash中有有效固件，BootROM会跳过去执行；如果没有固件，即使进入主Flash启动，也会因为Flash为空而停在某处，引脚不会有输出。但观察到方波说明Flash里确实有代码，而且它在运行。
我用ST-LINK连接板子，打开STM32CubeProgrammer连接目标，读取了选项字节和Flash内容。确认Flash里已经烧录了一个示例工程，而且这个工程的初始化代码把PG10配置为TIMx的PWM输出。这就完全对上了：主Flash启动模式下，用户固件执行，把PG10驱动为PWM，方波就出来了。
所以问题链清晰了：BOOT引脚电平组合错误 → BootROM选择了主Flash启动 → 用户固件运行 → PG10被配置为PWM输出 → 示波器看到4.3MHz方波 → 永远等不到BootFailed。整条链路，只要任何一环改变，结果都会不同。
4.3 用CubeProgrammer确认Flash状态和选项字节
具体操作路径是：打开STM32CubeProgrammer，选择ST-LINK接口，点击Connect。连接成功后，在左侧导航栏找到Option Bytes页面，查看BOOT相关的配置位。同时，在Memory界面读取Flash起始区域的内容，确认是否有有效的用户程序。
这里有个容易踩的坑：STM32CubeProgrammer连接目标时，如果目标正在运行用户程序，而用户程序把SWD引脚复用掉了，可能会连接失败。遇到这种情况，可以先按住板上的复位键，在CubeProgrammer点击Connect的同时松开复位键，利用上电瞬间的BootROM窗口建立连接。这个技巧在调试经常被引脚复用问题困住时非常管用。
我这次连接比较顺利，因为示例工程没有动SWD引脚。读取到的Flash内容显示，0x08000000处有有效的向量表，这进一步确认了Flash中存在可执行固件。如果Flash是空的，地址处应该是全0xFF或者0x00，启动后行为会完全不同。
5. 解决方案：让BootFailed按预期出现
问题定位之后，解决就变得简单直接了。根据排查结果，我需要做的就是把启动模式切到UART引导，让BootROM跳过用户固件，直接初始化UART5输出引导信息。当然，如果目标是清除或者更新固件，也可以直接用CubeProgrammer重新烧录。
方案其实有两个层次。一是只为了这次调试：把BOOT引脚拨到UART模式，验证BootROM输出。二是从根源上避免以后踩坑：在最终代码里加入正确的引脚初始化，避免把调试引脚复用为PWM，同时保留对启动模式的完整了解，防止下次烧错。两个方案我都做了，也是给读者的建议。
5.1 修改BOOT引脚设置，切换启动源
具体操作如下：找到开发板上的SW1（启动模式拨码开关），参考板子丝印和原理图，把BOOT引脚的组合拨到UART启动模式。某些STM32N6系列会自动识别USB/UART，不需要额外引脚选择，但N6570-DK上确认是有独立BOOT引脚的，所以我直接改了拨码。
设置完成后，先用万用表确认BOOT引脚的电平符合UART启动的要求。然后给板子重新上电（注意一定要彻底断电，不能只按复位键）。接着打开串口助手，波特率设置为115200，数据位8，停止位1。再把串口助手的接收显示切换为ASCII模式，方便读文本。
按上述步骤操作后的现象是：上电瞬间串口助手收到字符流，其中出现了预期的BootFailed字符串，后面跟着BootROM的引导提示符。同一时刻，把示波器探头放在PG10上，看到的波形变成了一段段的数据帧，空闲电平为高，起始位拉低，再也不是规则的方波。这说明BootROM已经接管UART5并且成功发出了调试信息。
5.2 清理Flash并重写UART初始化代码
如果不想保留那个会把PG10配成PWM的固件，最简单的办法是擦除Flash。用STM32CubeProgrammer连接ST-LINK，执行全片擦除，然后重新上电。这之后即使BOOT引脚处于主Flash启动模式，由于Flash为空，BootROM也会因为用户代码无效而回到某种默认处理，不会出现PWM方波。
更稳妥的做法是：保留一个精简的LED闪烁固件，但把UART5初始化代码写上，这样上电后既能通过PG10看到调试数据，又能验证整个链路。这里我贴一段简洁的UART5初始化逻辑，基于STM32CubeMX生成的代码做了精简：
void MX_UART5_Init(void) { huart5.Instance = UART5; huart5.Init.BaudRate = 115200; huart5.Init.WordLength = UART_WORDLENGTH_8B; huart5.Init.StopBits = UART_STOPBITS_1; huart5.Init.Parity = UART_PARITY_NONE; huart5.Init.Mode = UART_MODE_TX_RX; huart5.Init.HwFlowCtl = UART_HWCONTROL_NONE; huart5.Init.OverSampling = UART_OVERSAMPLING_16; if (HAL_UART_Init(&huart5) != HAL_OK) { Error_Handler(); } }同时确保GPIO复用配置正确：
GPIO_InitStruct.Pin = GPIO_PIN_10; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate = GPIO_AF8_UART5; // 以实际数据手册AF编号为准 HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);注意AF编号一定要参考STM32N6570数据手册的GPIO复用表，不同系列相同引脚号的AF映射可能不同。如果AF编号写错，引脚不会被复用到UART5，又会出现信号对不上的问题。
5.3 验证步骤与判断标准
修改完成后，我做了三轮验证。第一轮：BOOT引脚保持UART启动模式，上电后串口助手应收到BootROM的启动信息，示波器在PG10上看到UART数据帧。第二轮：把BOOT引脚切回主Flash启动，上电后PG10不再输出方波，而是输出我新固件里配置的UART调试日志，内容是我添加的"UART5 init OK"之类的字符串。第三轮：用STM32CubeProgrammer执行一次标准的UART下载流程，确认BootROM的引导链路完整，能够正常通信。
第三轮尤其重要，因为只看到BootFailed字符串说明BootROM在报错，但还不能证明引导链路完整可用。实际跑一次固件下载，才能在真实场景中验证UART5_TX的数据通路。这次测试我下载了一个小的LED控制程序，全程稳定，没有出现校验错误或者超时。
6. 常见问题排查速查与经验总结
这次调试涉及的知识点其实不多，但每一步都可能踩坑。我把常见问题整理成表，方便以后快速查阅。有些问题在这个项目里没遇到，但在其他板子上遇到过，一并列出来。
| 现象 | 可能原因 | 排查方向 | 解决方式 |
|---|---|---|---|
| 无任何信号 | 供电异常/时钟未起振 | 检查电源指示灯、量VDD/VDDA | 修复供电，确认晶振 |
| 有方波无UART数据 | 用户固件把引脚配置为PWM | 读GPIO复用寄存器/查固件初始化 | 擦除Flash/修改引脚配置 |
| 有乱码 | 波特率不匹配 | 确认BootROM波特率、串口助手设置 | 改为115200 8-N-1 |
| 有信号但很快消失 | 看门狗复位 | 检查IWDG配置 | 关闭看门狗或喂狗 |
| BootFailed出现但下载失败 | 校验失败/通信错位 | 检查连接线、电平、抗干扰 | 换线材/降低环境干扰 |
| 按复位键无变化 | 复位引脚被拉低 | 量NRST电平 | 检查复位电路 |
| 串口助手收不到数据 | TX/RX接反 | 检查杜邦线连接 | 交叉连接TX和RX |
6.1 容易忽略的几个关键细节
第一个是断电重启和软复位的区别。很多开发者改完BOOT跳线后，只按了板上的复位按键，结果发现行为没变。原因在于BootROM只在特定复位源（如上电复位）时读取BOOT引脚，软复位可能不会重新采样。遇到这种情况，直接断电再上电，问题往往就消失了。
第二个是示波器探头的地线。测量高频信号时，探头地线过长会引入振荡和噪声，可能掩盖真实信号。我记得有一次量一个UART信号，发现上面叠加了高频毛刺，换了个短地线弹簧后毛刺消失，信号干净了很多。这次量4.3MHz方波虽然没受影响，但养成好习惯很重要。
第三个是BootROM的引脚和用户固件里的引脚可能冲突。如果用户固件初始化了UART5但配置了不同的波特率，或者把PG10设为普通GPIO输出，那么BootROM打印的信息只会出现一小会儿，然后被用户代码接管。这就需要观察"启动瞬间"而不是"启动完成后"的信号。
第四个是关于方波的占空比。如果观察到的是50%占空比，大概率来自时钟分频或PWM；但如果占空比不是50%，通常考虑PWM输出，因为时钟分频天然产生接近50%的方波。这次实测的占空比非常接近50%，所以我在排查时把时钟输出也列入了候选，后来确认是PWM后，回头看其实是巧合。
6.2 排查此类问题的高效路径
经过这次调试，我的个人做法是：拿到一块新板子或者遇到奇怪的信号，第一件事不是打开IDE写代码，而是先做"上下电观察"。用示波器或者逻辑分析仪，单次触发捕捉上电到稳定之间所有IO变化。这个画面能告诉你的信息，远比看代码多。
第二步是读手册。重点读启动章节和GPIO复用表。启动章节告诉你BootROM怎么走，GPIO复用表告诉你怎么查引脚当前功能。这两份资料配合使用，能覆盖绝大多数类似问题。
第三步才是动手改。改完之后一定要验证两个层次：硬件上看到了正确的信号，软件上配置是正确的。不要只看串口打印了数据就说"通了"，还要确认波形特征确实符合UART协议，因为有时候错误配置下的信号看起来很像数据，但实际完全不能用。
这次排查花了两三个小时，大部分时间用在了确认BOOT引脚电平这个问题上。回头想想，如果一开始就用万用表量一下BOOT引脚，可能十分钟就定位了。但这也正是嵌入式调试有意思的地方：每个看似反常的现象背后，都有一个明确的技术原因，挖出来之后，整个系统的行为模式就清清楚楚了。最后再分享一个小技巧：遇到这种"预料之外"的信号，先别急着改代码，把示波器探头在板上多挪几个点，量一量相邻引脚有没有类似频率的方波。如果多个引脚都有同样的信号，那大概率是时钟或者总线信号串出来的，和GPIO本身无关；如果只有目标引脚有，那就是这个引脚自己的复用配置出了问题。这个判断方法在很多调试场景里帮我省了不少时间。
