Bootloader跳转前必须校验APP完整性并重置运行环境：先验签或CRC校验整个镜像，再加载向量表、设置MSP、执行__init_array构造器、关中断后跳复位向量。
跳转前必须校验应用程序的完整性与合法性
直接跳转到未知地址等于把控制权交给不可信代码，Bootloader 的核心职责不是“跳过去”，而是“确认能跳”。常见做法是校验 APP 的 CRC32 或 SHA256（嵌入式常用 CRC16/CRC32），校验位置通常在 APP 的起始段或专用校验区。若校验失败却强行跳转，轻则跑飞，重则破坏 Flash 或外设寄存器状态。
- 校验范围必须包含整个可执行镜像（不含 Bootloader 自身），建议将校验值放在 APP 的末尾或独立扇区，并在链接脚本中用
_app_checksum_start和_app_checksum_end显式标记 - 避免只校验头部几个字节——攻击者可伪造合法头但替换后续代码
- 若使用加密签名（如 RSA/ECDSA），需确保公钥固化在 Bootloader 只读区，且验签逻辑无侧信道漏洞
跳转前必须重置并初始化运行环境
C++ 应用程序依赖特定的初始状态：栈指针、中断向量表位置、全局对象构造器、__libc_init_array 等。Bootloader 通常运行在自己的栈和向量表上，不重置就跳转会导致 main() 执行时访问非法内存或触发未定义中断。
- 手动加载 APP 的向量表基址到
SCB->VTOR（Cortex-M）或等效寄存器；否则所有异常（包括 HardFault）都会跳回 Bootloader 的向量表 - 设置新的主栈指针（MSP）为 APP 链接脚本中定义的
_stack_top（不是 Bootloader 的栈） - 显式调用 APP 的
__init_array_start到__init_array_end区间内所有函数指针（即 C++ 全局对象构造器），否则std::cout、静态std::string等会崩溃 - 禁用所有 Bootloader 使能的中断（如 SysTick、UART），避免跳转后中断服务例程仍在执行旧上下文
跳转地址必须是复位向量而非 main 函数入口
ARM Cortex-M 的复位向量（地址偏移 0x04）存放的是初始 MSP 值，0x00 是复位处理函数地址。直接跳到 main 地址绕过了启动代码（Reset_Handler），不会初始化 .data/.bss 段、不调用 __libc_init_array、不配置系统时钟——C++ 运行时根本没准备好。
- 从 APP 的 Flash 起始地址（如
0x08008000）读取第 2 个字（偏移 0x04）作为新 MSP，第 1 个字（偏移 0x00）作为跳转目标 - 务必用函数指针类型强制转换，例如：
typedef void (*func_ptr_t)(void); func_ptr_t app_reset = (func_ptr_t)(*(uint32_t*)(APP_BASE + 4)); - 跳转前关中断（
__disable_irq()），跳转后由 APP 的Reset_Handler再开——避免在切换瞬间被中断打断栈切换过程
跳转后无法返回，且调试信息极易丢失
一旦执行 app_reset()，PC 指向 APP 的复位向量，Bootloader 的栈帧、变量、调试符号全部失效。JTAG/SWD 调试器可能断连，或继续停在 Bootloader 断点而看不到 APP 执行流。
- 在跳转前通过 UART/LED 留下明确标记（如发送
"JUMP:0x08008000"），确认跳转动作已发出 - APP 必须自带最小化自检（如翻转某 GPIO、输出启动字符串），否则“静默失败”无法区分是跳转失败还是 APP 本身卡死
- 不要依赖 Bootloader 的 printf 或 malloc —— APP 的堆/stdio 初始化尚未开始，这些调用会跳转到 Bootloader 的实现，造成地址错乱或死锁
实际中最容易被忽略的是全局对象构造器的执行时机——C++ 开发者习惯写 static std::vector，却没意识到这个对象的构造函数根本不会被调用，除非 Bootloader 主动遍历 .init_array。这问题在裸机环境下没有运行时兜底，出错时连 Crash 日志都打不出来。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
