如果你拿到一块STM32G0B1KCT6，费尽心思把Open Bootloader移植好，用ST-Link在调试器里跑了一整天，CAN升级流程丝滑顺畅、跳转APP也正常。可一旦拔掉调试器，让板子独立上电，通过CAN烧写应用程序后，芯片就像死了一样——或者卡在Bootloader，或者跳过去就HardFault。这个现象在Bootloader开发中太经典了，通常一句话就能概括：调试器掩盖了问题，Flash启动放大了问题。
我见过太多人卡在这个坑里，包括我自己。STM32G0系列的时钟树、Option Bytes、FDCAN外设复位行为都有不少和F1/G0老型号不一样的地方，恰恰是Bootloader最容易踩的地方。这篇就把这类问题的完整排查链路拆开讲清楚，从底层差异到具体修复方案，给正在做G0B1KCT6 CAN升级的朋友一个可以直接照做的思路。
1. 先弄清楚"Debug正常"和"Flash启动"之间的五个差异点
1.1 调试器接通后，到底替你干了多少活
很多人觉得调试器只是"把固件下载进去"，其实ST-Link通过SWD连上芯片后做的事远不止这些：它会先复位内核并让CPU停在Reset状态，读取芯片的IDCODE、Flash容量、Option Bytes，再按你选择的烧录算法把固件写入Flash，最后复位运行。
这里有一个几乎是"隐形杀手"的点：SWD调试器下载程序时，是整体擦除并重写Flash，而工程里的Flash Algorithm会负责配置等待周期和擦写时序，这部分逻辑和Bootloader自己在CAN升级时写的擦写代码完全不是一回事。调试器能跑，只能说明你的逻辑在"SWD完整烧录+标准初始化"下是对的，并不能证明你的Bootloader在"自擦写+自跳转"下也是对的。
另一件容易忽略的事是供电。很多评估板直接把ST-Link的3.3V或者5V引出来给目标板供电，这个电源虽然算不上多干净，但至少稳定。一旦拔掉调试器改用外部电源，电压跌落、启动毛刺、纹波这些问题就全部暴露了。如果你的板子是自制的，先把供电差异排除掉，再往下查软件。
1.2 冷启动和热启动，寄存器初始值完全不同
这是很多人忽略的一个根本差异。调试器运行Bootloader时，通常是先执行一次复位，然后CPU从0x08000000开始跑，此时所有外设寄存器都是复位初值，这是典型的冷启动。而通过CAN升级完成、Bootloader直接跳转到APP时，CPU并没有经历复位，大部分外设寄存器还停留在Bootloader使用时的值，这是热启动。
对STM32G0B1KCT6来说，最常见的热启动问题有两类：
- RCC里的外设时钟使能位、外设复位位保持Bootloader状态，APP的
SystemInit没有把时钟树完全还原； - FDCAN外设收到过报文，FIFO和中断标志还挂着，APP初始化时没有清理，第一个进入的中断就跳到了错误的位置。
这些差异在Debug模式下被掩盖了，因为每次调试器加载都会复位芯片，外设状态天然是干净的。等你脱离调试器走CAN升级，热启动的各种残留就全冒出来了。
1.3 Debug构建和Release构建的差异也别忽视
如果项目里同时存在Debug和Release两套构建配置，先确认你对比的是不是同一份代码、同一个优化级别。Debug默认是-O0，Release经常是-O2，某些依赖时序或未初始化变量的代码在这种切换下行为会大相径庭。
常见的是：assert_param()宏在Debug下会调用错误处理函数、打印信息，在Release下被编译掉；某个局部变量没初始化，Debug下侥幸是0，Release下恰好是垃圾值。虽然这类问题不如前两个普遍，但一旦踩中，排查起来非常耗时。建议先用同一份Release固件分别通过SWD和CAN烧录，对比现象是否一致，把变量控制住再动手。
2. 排查第一步：确认APP的链接地址与烧录地址是否真的匹配
2.1 Bootloader把APP放哪儿，不是拍脑袋定的
一个典型的Flash划分长这样：
| 区域 | 起始地址 | 大小 | 内容 |
|---|---|---|---|
| Bootloader | 0x08000000 | 32KB | Open Bootloader |
| APP | 0x08008000 | 192KB | 应用程序 |
| 参数区 | 0x0803F000 | 4KB | 升级标志、版本号、CRC |
不管怎么划分，Bootloader在CAN收到固件后把数据写入的目标地址，必须和APP工程的链接地址严格一致。最常见的错误是：Bootloader把APP写到0x08008000，但APP工程在CubeIDE或者Keil里没有改起始地址，默认还是链接在0x08000000。这样烧进去的APP，前32KB覆盖了Bootloader，其余内容整体错位，跳转时读0x08008000处的MSP和PC，读出来不是零就是垃圾数据，大概率一进去就HardFault。
2.2 为什么Debug模式下根本发现不了
这是经典的“调试器掩盖问题”时刻。当你用ST-Link调试APP工程时，调试器默认按APP工程里配置的链接地址下载，如果APP链接地址默认是0x08000000，调试器就把APP写到0x08000000，直接覆盖掉Bootloader。此时能跑，是因为它压根没经过Bootloader，CPU从0x08000000启动后直接执行的是你的APP。
而通过CAN升级时，APP被Bootloader写到0x08008000，但APP内部所有绝对地址、中断向量表都是按0x08000000链接的，在0x08008000上执行几乎必挂。所以排查前先问自己两个问题：
- 你调试的是Bootloader工程，还是APP工程？
- 这两个东西实际跑的是不是同一个Flash地址？
如果调试APP时一切正常，但通过Bootloader跳转以后就不行，九成是地址错位。
2.3 读回Flash对比是最直接的验证方法
不要靠猜，直接读Flash。用STM32CubeProgrammer或者任意一款支持内存读取的调试工具，分别读出0x08000000和0x08008000开头的4KB数据，和你的Bootloader Bin、APP Bin做逐字节对比。正常情况应该是：
- 0x08000000开头是Bootloader的栈顶地址和Reset_Handler地址；
- 0x08008000开头是APP的栈顶地址（0x20000000附近）和APP的Reset_Handler地址（0x08008000附近）。
如果0x08008000处还是全0xFF，说明CAN烧录流程根本没有把数据写进去，或者在某个环节被骗了；如果写进去了但栈顶值不在SRAM范围内，那一跳转就进HardFault就完全说得通了。
3. 排查第二步：Option Bytes——两条烧录路径上的"隐形分叉"
3.1 为什么同一颗芯片，烧录路径不同Option Bytes会不一样
STM32G0系列的Option Bytes里，对启动流程影响最大的几个是：RDP（读保护等级）、WRP（写保护区域）、BOR_EN/BOR_LEV（上电复位阈值）、nBOOT0/nBOOT_SEL/nBOOT1（启动源选择）。
通过SWD烧录时，ST-Link和CubeProgrammer会自动管理这些位的状态。比如芯片当前RDP为Level 1，CubeProgrammer连接时会提示你需要先降级，降级过程中触发整片Mass Erase。而你的Bootloader通过CAN写Flash时，基本不会去动这些Option Bytes，两边状态就容易出现差异。最要命的是，这些差异通常不会在Debug时暴露，只在脱机独立运行时跳出来。
3.2 RDP/WRP在升级链路中的真实影响
先说一个容易误会的点：写保护（WRP）保护的是Flash的写入和擦除，并不影响CPU执行Flash里的代码。所以"APP跑不起来"一般不是WRP直接导致的。但WRP会让Bootloader的Flash擦写操作卡在等待BSY标志清零的循环里，表现就是CAN升级流程假死或者超时。如果你在Bootloader里没有正确检查WRP状态，目标地址被写保护了，擦写操作永远无法完成，而Bootloader又没做超时退出，看起来就是"升完级不跑"。
RDP更隐蔽。如果调试器烧录时芯片RDP是Level 0，一切都正常；如果Bootloader代码里有"升级完成后自动把RDP设为Level 1"的逻辑，下次通过SWD连接芯片时，调试器检测到RDP已经是保护状态，需要Mass Erase才能降级。如果你在Bootloader的跳转或复位序列里误触发了RDP降级，整片Flash会被擦干净——表现同样是"烧完了，跑不起来，重新读Flash是一片0xFF"。
建议：在CAN升级链路联调阶段，先把RDP和WRP的相关逻辑全部注释掉，保持Level 0、无写保护，跑通整个链路后再单独加保护逻辑。千万不要一开始就开着RDP调Bootloader，那是给自己挖坑。
3.3 BOR等级在独立上电时最容易出事
调试器连接时，很多情况下芯片供电由ST-Link提供，电压稳定。独立工作后改用外部电源，电压在启动瞬间可能跌落，如果BOR阈值设置不合理，芯片会不停复位，表现为"烧录成功但不工作"。
G0系列的BOR可配置多个等级，最高等级对应约2.8V到3.15V的阈值区间，具体数值以对应型号的数据手册为准。如果你的板子用3.3V供电，BOR又设在最高档，启动瞬间电压一波动就会触发BOR复位。Bootloader运行过程中如果调用了s HAL_FLASH_OB_Program修改BOR，这个影响会一直延续到APP独立运行阶段。
排查方法很直接：用CubeProgrammer的Option Bytes窗口读当前BOR_LEV值，把它降到最低档（或者使用默认POR）再试。如果问题消失，基本就是BOR阈值和电源电压顶得太紧。
3.4 从Bootloader端管理Option Bytes的正确姿势
如果确认必须由Bootloader在升级时设置Option Bytes，不要直接对着寄存器敲，G0的OB编程有比较严格的双解锁序列，容易写错。用HAL库反而更安全：
HAL_FLASH_OB_Unlock(); /* 设置RDP为Level 0，清除WRP，BOR用最低档 */ HAL_FLASH_OB_Program(OB_RDP_LEVEL_0, 0); HAL_FLASH_OB_Lock(); HAL_FLASH_OB_Launch(); /* 触发OB装载，会引发系统复位 */注意HAL_FLASH_OB_Launch()会导致芯片复位，如果你在它之后又立即执行跳转函数，复位时序会和预期冲突。建议写法是：先把固件、升级标志、Option Bytes全部准备好，最后只调用一次复位，让芯片以干净状态重新上电，再由Bootloader启动代码判断标志去跳APP。
4. 排查第三步：跳转函数里那些"调试器帮你掩盖"的状态残留
4.1 Cortex-M0+跳转APP的标准动作
跳到APP本身动作很简单：设置MSP、设置PC。但干不干净决定成败。下面这个跳转函数是我在生产项目里验证过的，顺序是有讲究的，每一行都有目的：
typedef void (*app_entry_t)(void); void jump_to_app(uint32_t app_addr) { uint32_t msp = *(uint32_t *)app_addr; uint32_t pc = *(uint32_t *)(app_addr + 4); /* 1. 合法性检查，防止跳到垃圾地址 */ if ((msp < 0x20000000) || (msp > 0x20024000)) return; if ((pc < 0x08000000) || (pc > 0x08040000)) return; /* 2. 关全局中断，停掉SysTick */ __disable_irq(); SysTick->CTRL = 0; /* 3. 把挂起中断全部清掉，并关闭所有外部中断 */ for (uint
