引导程序用于固件升级，但应用程序无法启动

发表于 2026-9-9 10:19

你的跳转函数中重复调用了HAL_DeInit和HAL_RCC_DeInit，这会复位所有外设时钟，但USB和文件系统相关外设在跳转前可能还没有完全释放，导致应用程序启动时外设状态异常。

发表于 2026-9-9 12:37

是直接跳转还是通过复位跳转？

发表于 2026-9-9 13:29

有开发者遇到过类似问题，原因是跳转前没有禁用所有已使能的中断，特别是USB和FATFS相关的中断，跳转后这些中断触发时应用程序的中断向量表还未就绪，直接进入HardFault。

发表于 2026-9-9 13:46

引导程序是否正确加载？

发表于 2026-9-9 14:45

你的goto_application函数中定义app_reset_handler为((volatile uint32_t*) (APP_ADDRESS + 4U))，这是把地址值直接当作函数指针，缺少了取内容操作符*，实际跳转到了一个随机地址。

发表于 2026-9-9 15:40

最简单的验证方法：写一个最小应用程序，只点亮LED和闪烁，不依赖任何外设中断，看能否启动。如果最小程序能启动，说明是应用程序的外设初始化顺序或中断向量表问题。

发表于 2026-9-9 15:50

Bootloader 端跳转代码完全正确，如果 APP 的 main() 函数开头没有重新设置 SCB->VTOR，APP 的中断仍然指向 Bootloader 的向量表，触发中断时会跳转到错误的地址，导致 HardFault 或复位。

发表于 2026-9-9 16:10

从U盘读取的bin文件如果是通过IDE直接生成的，可能包含了0x08000000作为链接基址，你需要使用fromelf或objcopy工具将bin文件转换为偏移后的格式，或者修改应用程序的链接地址。

发表于 2026-9-9 16:58

APP 是完全没有反应，还是启动后某些外设不工作？

发表于 2026-9-9 19:47

建议先通过调试器在跳转地址设置断点，单步执行第一条跳转指令，观察MSP是否设置为正确的栈顶值，以及PC是否进入应用程序的Reset_Handler，确认硬件层面的跳转是否成功。

发表于 2026-9-9 19:48

多份跳转函数中都用__disable_irq()禁用全局中断，但在跳转后没有对应的__enable_irq()，应用程序启动时中断全局关闭，systick等任何中断都无法触发，系统会卡死。

发表于 2026-9-9 20:36

Bootloader 和 APP 的 Flash 分区地址？

发表于 2026-9-9 21:22

你的Nucleo-F413ZH有1.5MB Flash，但双Bank Flash可能导致写入地址计算错误。检查你的擦除和写入函数是否正确处理了跨Bank边界的情况，写入了错误地址的Flash。

发表于 2026-9-9 22:49

跳转前对NVIC的ICER和ICPR寄存器操作时循环了5次，但F413ZH的NVIC有更多中断线，可能还有中断没有被清除干净，跳转后这些挂起的中断会立即触发导致异常。

发表于 2026-9-10 08:55

Bootloader 可能配置了特定的系统时钟，而 APP 启动时 SystemClock_Config() 会重新配置时钟。如果跳转前没有将时钟恢复为默认状态，APP 重新配置时钟时可能因为 HSE 已开启、PLL 已锁定等状态而卡死或失败。

发表于 2026-9-10 09:14

你的VTOR设置对了，但检查一下是不是在跳转之前MSP（主栈指针）设置了正确的值，有时候栈溢出也会导致程序无法启动。

发表于 2026-9-10 14:42

核心检查：中断向量表重定位

发表于 2026-9-10 18:22

升级写入 Flash 成功、校验通过，但跳转 App 时卡死 / 直接回到 bootloader

发表于 2026-9-10 22:23

Bootloader 和 APP 的 Flash 区域不能重叠，APP 的链接脚本必须正确反映其实际烧录地址。

发表于 2026-9-10 22:49

跳转前先关全局中断并设置 SCB->VTOR=0x08010000，app 工程按该地址重定位向量表，同时检查 bootloader 是否改过时钟配置。

[STM32F4] 引导程序用于固件升级，但应用程序无法启动