STM32F469AIHX当使用 Boot和App分区主频超过 128MHz 时系统崩溃

发表于 2026-9-19 12:28

我正在为 STM32F469AIHX 开发一套采用 Boot 与 App分区的固件，用于 OTA 固件升级。
当 Flash 被划分为 Boot 和 App 两个区域时，系统在 180MHz 下无法正常工作。然而，将内核时钟设为 128MHz 则一切正常。此外，Application 单独从地址 0x08000000 运行时，在 180MHz 下工作正常。

我已经排查过的
将 CubeMX 配置恢复为默认，仅修改了 Flash 内存布局
确认 VTOR 已正确设置为 APPLICATION_ADDRESS
确认 SysTick_Handler 中调用了 HAL_IncTick ()
确认跳转到 App 后、在 180MHz 下运行时 uwTick 不再递增
在 Bootloader 跳转前移除了 HAL_RCC_DeInit () / HAL_DeInit ()
在 Application 的 main () 中、HAL_Init () 之前先设置 SCB->VTOR

Bootloader 跳转代码

__disable_irq();

SysTick->CTRL = 0;
SysTick->LOAD = 0;
SysTick->VAL = 0;

SCB->VTOR = APPLICATION_ADDRESS;

JumpAddress = *(__IO uint32_t*)(APPLICATION_ADDRESS + 4);
JumpToApplication = (pFunction)JumpAddress;

__set_MSP(*(__IO uint32_t*)APPLICATION_ADDRESS);

JumpToApplication();

为什么只有在使用 Boot + App 分区时，180MHz 才会失效？
从 Bootloader 跳转到 Application 时，是否有特定的 RCC 或 Flash 等待周期配置要求？

发表于 2026-9-19 15:40

这个现象很典型:Boot+App 时 180MHz 挂、128MHz 好,而且单独从 0x08000000 跑 App 在 180M 也正常。说明问题不在 App 本身,而在'Boot 跳 App 时的时钟/Flash 等待周期状态'。关键点:**F469 在 180MHz 需要 Flash 等待周期设为 5WS(F4 系列 168M+ 要 5 个等待周期)**。如果 App 里 SystemClock_Config 设 180M 但 Flash WS 没配对,就会在跳转后崩。

发表于 2026-9-19 15:41

我赌根因是 App 的时钟配置依赖了 Boot 留下的状态,而 Boot 在低主频时 Flash WS 配的是较小值。跳转后 App 直接改 PLL 到 180M,但 Flash 还按旧 WS 读指令,CPU 取指出错就崩。解决:App 在 SystemClock_Config 里先把 Flash WS 设到 5,再切 180M;或者 Boot 跳转前就把 Flash WS 设成 5。

发表于 2026-9-19 15:42

补充个 F4 细节:F469 的 180MHz 是超频档,必须开 **ART Accelerator + Prefetch + 正确的 WS(5)**。另外 180M 下 VOS 要选 Scale1,F4 的电压调节器档位不对也跑不稳。检查 App 的 SystemClock_Config 里 HAL_PWREx_EnableOverDrive() 和 VOS 设置,这两个没配 180M 必崩。

发表于 2026-9-19 15:43

想问下你 Bootloader 的 SystemClock_Config 跑在多少主频?很多人的 Boot 跑 16M(HSI)省电,跳转时 Flash WS=0。App 期望的初始状态(WS=5)和实际(WS=0)不符,App 又没重配 WS 就上 180M,自然崩。**核心是'App 不能假设跳转进来时的 Flash WS 是它需要的'**,必须自己重配。

发表于 2026-9-19 15:43

从你排查的现象'uwTick 在跳 App 后不再递增'看,说明 App 起来后 SysTick 没跑起来,系统卡在很早期(可能刚进 main 就崩)。这更佐证是时钟/Flash 配置问题——很可能 App 在 SystemClock_Config 里切 180M 时挂了。先把 App 的 SystemClock_Config 单独从 128M 改到 180M 测,确认是这步的问题。

发表于 2026-9-19 15:44

补充:HAL_RCC_ClockConfig 在切 180M 时会更新 Flash WS,但更新顺序和超频档的顺序在某些 HAL 版本里有讲究(要先开 OverDrive、等 VOS ready、再切频率)。如果你的 HAL 版本顺序有问题,切 180M 就会在不该崩的地方崩。建议手动按'WS→VOS→PLL'的严格顺序配一次。

发表于 2026-9-19 15:45

测试建议:在 App 的 SystemClock_Config 开头和结尾各点一个 LED / 打一句串口,看它到底走到哪崩。如果进 main 就没出来,是被跳转或时钟初始化卡住;如果是切 180M 时挂,就锁定时钟配置。别只看'崩'这个结果,要定位崩的位置。

发表于 2026-9-19 15:46

我之前做 F4 OTA 也踩过类似的,教训是:**Boot 和 App 的时钟/Flash 状态要显式解耦**。要么 Boot 跳转前把外设时钟复位(HAL_RCC_DeInit 后再配成 App 期望的),要么 App 假设'什么都没配'从头配。你试过移除 HAL_RCC_DeInit,那反过来,干脆加上并让 App 全量重配试试。

发表于 2026-9-19 15:46

问一句:你 App 单独跑 0x08000000 是在 Boot 也是同一套代码里吗?还是完全独立的工程?如果是独立工程,它的 SystemClock_Config 是自洽的;一旦塞进 Boot+App,App 的时钟配置可能被 Boot 的残留状态影响。建议把 App 的时钟配置改成'不依赖任何先前状态'的完整初始化。

发表于 2026-9-19 15:47

从 F4 手册的电压/频率关系看,180MHz 是最高档,对 Flash WS、VOS、OverDrive 三者的配置顺序和完整性要求最严。128M 以下这些参数宽松,所以'低频好、高频崩'完全符合'高速档配置不完整'的特征。建议照 CubeMX 生成的 180M 时钟配置逐行核对 App 的 SystemClock_Config,尤其 WS 和 VOS。

[STM32F4] STM32F469AIHX当使用 Boot和App分区主频超过 128MHz 时系统崩溃

浏览过的版块