企业官网建设流程全解析

去年有个项目用了一颗 STM32G031 做低功耗传感器节点，Stop 模式唤醒后经常出现“外设配置丢失但 RAM 数据还在”的诡异现象。排查到最后，问题不是出在应用代码，而是我对这颗芯片的启动流程和 ROM/RAM 协作方式理解得不够透彻。当时翻了不少资料，发现大部分文档都在讲“复位后第一行代码”这种概念，真正把启动链路、向量表、数据段搬移、链接脚本串起来讲清楚的很少。这篇文章就是想把这些内容补上，从实际调试的角度，把 STM32G031 的启动流程从头到尾拆一遍，重点说清楚 ROM 和 RAM 在里面各自扮演什么角色、怎么配合，以及启动异常时该怎么定位。

适合谁看？刚接触 STM32G031 或者 Cortex-M0+ 内核的开发者，以及那些“程序能跑但不知道是怎么跑起来”的人。读完你会知道：从复位到 main 函数之间到底发生了什么、链接脚本里 FLASH/RAM 的划分如何约束启动行为、为什么全局变量的初始值不是“自带”的、没有 VTOR 的 M0+ 内核做中断向量重映射时有什么限制。这些都是实际写代码时会遇到的问题。

1. 上电后的第一行代码：从复位向量到 main 的完整链路

1.1 复位向量不是“第一行代码”，而是地址表的第一项

很多人习惯说“复位后执行第一行代码”，这个说法其实不准确。Cortex-M0+ 内核复位后，硬件做的事情非常机械：从地址0x00000000读出初始栈指针 SP 的值，从地址0x00000004读出复位向量（Reset_Handler 的地址），然后跳转执行。也就是说，处理器不是“执行”地址0x00000004里的内容，而是把0x00000004当成一个指针，取出的数值才是真正的执行地址。

这里有个 STM32G031 特有的细节：芯片的 Flash 可以通过0x08000000访问，同时还会被映射到0x00000000的别名区。所以你在调试器里给0x00000000和0x08000000同时下断点时，命中的是同一块物理 Flash。我第一次看到映射表时也有点懵，后来在调试器里验证过，这两个地址读取到的数据完全一致。这块别名映射的意义在于：Cortex-M0+ 是固定向量表地址的，没有 VTOR 寄存器，必须把向量表放在启动地址0x00000000，而 STM32 的 Flash 恰好能被映射到这里，所以向量表可以直接放在用户 Flash 的起始位置。

有趣的是，0x00000000其实是“代码区”的别名，并不是 Flash 本身的物理地址。G031 内部并没有一块真正位于地址0x00000000的存储器，这是总线矩阵做的地址重映射。硬件这样设计，是为了让 Cortex-M0+ 这个固定的取指机制能够适应不同的存储器配置。

1.2 堆栈初始化与 RAM 的第一次交集

复位后处理器从0x00000000读取的 SP 初始值，本质上是一个RAM地址。这个值不是硬件算出来的，而是链接脚本在构建阶段写进向量表第一项的。也就是说，RAM 在代码运行之前就已经参战了——它的存在方式是通过“向量表里预置的栈顶地址”这个静态约定。

G031 的 SRAM 起始地址是0x20000000，不同容量的型号栈顶值不同。比如手头这颗 Flash 64KB、SRAM 8KB 的型号，链接脚本通常会把栈顶设置为0x20000000 + 8KB = 0x20002000。但需要留意，拨码开关或调试器修改的栈指针只影响当前复位周期；如果烧录的固件链接脚本改变，栈顶值也会跟着变。很多人排查“程序跑飞”时，第一步就是看复位后 SP 是否为预期值，这一步就是从硬件机制上验证 RAM 栈顶是否设置正确。

硬件自动加载 SP 之后，处理器才会执行 Reset_Handler 的第一条指令。在 Reset_Handler 里，代码还会做一次 SP 重设，常见写法是：

ldr r0, =_estack mov sp, r0

这个操作看起来多余，但实际很有必要。因为在某些情况下（比如从 BootLoader 跳转过来的应用），复位向量表里的 SP 不一定就是当前运行环境需要的栈顶，显式设置一次可以确保栈处于可控状态。另外，这也是启动代码第一次真正访问 RAM——写 SP 寄存器不会直接访问 RAM，但后续第一个函数调用压栈时就会立刻用到 RAM 空间。

1.3 SystemInit 与时钟切换：ROM 里的代码决定 RAM 的运行节奏

Reset_Handler 接下来通常会调用SystemInit，这个函数的代码位于 Flash（也就是 ROM）中，由启动文件或库文件提供。SystemInit的主要工作包括：配置 Flash 等待状态、设置时钟源、可能使能 PLL 并切换系统时钟。

为什么时钟配置必须在 main 之前做？因为 flash 读取速度、外设总线频率、定时器基准都依赖时钟树。如果 SystemInit 不把 PLL 配置好，后面的代码可能还在用默认的 HSI16（16MHz 内部高速振荡器），但链接脚本、外设初始化代码都是按目标主频设计的，容易出现“慢得出奇”或者“外设定时不准”的问题。更关键的是 Flash 等待状态：当 HCLK 超过某阈值时，Flash 读取必须插入等待周期，否则取指就会出错，表现就是复位后跑几步就 HardFault。

我见过一个典型问题：工程师把 SystemInit 里配置 Flash 等待状态的部分注释掉，然后跑 64MHz 主频，结果程序在初始化流程里随机崩溃。后来把等待周期恢复，问题立刻消失。这类问题排查起来很隐蔽，因为现象是“随机死机”，第一反应往往是数组越界或者指针错误。所以这里建议：凡是改过时钟树，先查 Flash 等待状态是否匹配。

2. 启动文件逐段拆解：ROM 与 RAM 协作的现场

2.1 向量表存放规则与链接脚本的配合

启动文件（startup 文件）是 ROM/RAM 协作的“总调度室”。STM32G031 的启动文件里，第一段就是一个叫.isr_vector的段，里面按顺序放着一张表：第一个元素是初始 SP，第二个元素是 Reset_Handler，后面是各类中断处理函数指针。

关键在于链接脚本必须把这个.isr_vector段放到 Flash 的起始位置，也就是0x08000000。如果链接脚本的 FLASH 起始地址写错了，或者段的放置顺序错了，向量表就会跑到别的地方，复位后处理器会从错误位置取值，结果就是跑飞或者压根不启动。

一段典型的启动文件开头长这样：

.section .isr_vector,"a",%progbits .type g_pfnVectors, %object .size g_pfnVectors, .-g_pfnVectors g_pfnVectors: .word _estack .word Reset_Handler .word NMI_Handler .word HardFault_Handler .word 0 .word 0 /* 其余中断向量 */

注意到中间有两个.word 0，这是保留向量。MCU 的保留向量位置必须保持占位，不能随意删除，否则后续向量会整体错位。实际调整启动文件或链接脚本时，可以用编译生成的 map 文件来核对每个向量是否落在预期地址。我调试时经常打开 map 文件搜g_pfnVectors，看它的加载地址是否为0x08000000，这是最快验证向量表放置的方法。

2.2 数据段搬移：从 ROM 到 RAM 的“搬家”为什么必须做

C 语言里写uint8_t flag = 1;，看起来flag天生就有了值 1。但 ARM 内核并不会“记住”这个初始值——Flash 只能只读执行，不能随便写变量。实际上链接器把“1”这个初值放在了 Flash 的只读区域（.data_init或类似段），然后在启动阶段由代码把 Flash 里的初值拷贝到 RAM 中flag对应的地址。

这个拷贝过程在启动文件里是一个循环。GNU 工具链下常见的伪代码：

ldr r0, =__data_start__ ldr r1, =__data_end__ ldr r2, =__data_init copy_loop: ldr r3, [r2], #4 str r3, [r0], #4 cmp r0, r1 blt copy_loop

逐字翻译就是：从 Flash 的__data_init地址读一个字，写到 RAM 的__data_start__地址，然后两个指针都前进 4 字节，直到 RAM 里的目标空间被填满。这个过程直接展示了 ROM 和 RAM 的本质协作：ROM 提供“初值模板”，RAM 提供“运行变量实体”，启动代码负责把模板复制到实体。

ARM Compiler（比如 Keil MDK 的 ARMCC/AC6）里，这个工作被封装在__main中，通过分散加载机制完成。你可以在调试器里看到__main的执行路径，它会调用__scatterload_copy和__scatterload_zeroinit之类的内部函数。虽然工具链不同，但原理完全一致——无非是“谁来做和怎么做”的区别。

2.3 BSS 清零：为什么必须把“未初始化变量”初始化为零

BSS 段是“被 C 语言规定初始化为 0”的全局变量区域。C 标准要求未显式初始化的静态/全局变量初始值为 0，但 Flash 里不会为这块区域保留模板，因为全 0 不需要模板。启动代码要做的是把这段 RAM 逐个字清零：

ldr r0, =__bss_start__ ldr r1, =__bss_end__ mov r2, #0 zero_loop: str r2, [r0], #4 cmp r0, r1 blt zero_loop

如果这段清零被跳过或没跳到，就会出现一种很坑的现象：程序跑起来了，但全局变量初始值是随机垃圾数据，可能是上次运行残留，也可能是 RAM 上电噪声。这种问题最难查，因为表面上看不到任何崩溃点，只有某些 if 判断在随机触发。我做过一个实验，故意注释掉 bss 清零逻辑，灯板初始化后每次上电显示都不一样，就是因为状态标志位有残留值。遇到这类问题，请先确认链接脚本里的__bss_start__/__bss_end__符号是否正确，以及启动汇编是否真的调用了清零循环。

2.4 堆栈与堆的设置：SRAM 小容量下的谨慎分配

G031 的 SRAM 只有几 KB，启动阶段对栈的分配必须仔细。在链接脚本里，栈顶_estack通常被设置为 RAM 末尾，然后把栈大小定义为一个固定值：

_estack = ORIGIN(RAM) + LENGTH(RAM);

栈是向下生长的，所以栈顶设在最高地址、栈底往下走，天然不与数据段、BSS 段冲突——只要数据段和 BSS 段从 RAM 起始地址向上增长，两者互不干扰。但如果你把一个大数组声明成局部变量，它会在栈上分配，栈底可能追到数据段的增长区域，引发溢出。G031 上这个碰撞非常隐蔽，因为 SRAM 太小，溢出后往往不会立刻崩，而是先破坏某个全局变量或者中断现场，等几秒后才出问题。

堆（Heap）在裸机项目中通常是可选的。如果你不使用malloc或标准库的文件操作（比如printf重定向到 UART 可能用到浮点或 FILE 结构），可以把堆大小设成 0 或一个极小值。堆和栈共享一片 RAM 区域，堆从低地址向上增长，栈从高地址向下增长，两者相向而行。中间剩余的 RAM 是它们的活动空间，如果缓冲区耗尽，就可能在两者之间碰撞。G031 上我倾向于明确的“栈优先”策略：栈给足，堆能省就省。毕竟你上 MCU 不是因为要跑 Java，而是因为要精确控制硬件。

3. ROM 与 RAM 的职责边界：哪段代码在哪运行，为什么这么分

3.1 代码和只读数据为何留在 ROM 里执行

Cortex-M0+ 没有像某些 DSP 那样需要把代码复制到 RAM 才能跑的机制。Flash 本身就是通过总线直接映射到代码空间的，处理器可以就地取指执行，这被称为 XIP（原地执行）。所以用户代码、中断处理函数、常量字符串、const数组都会留在 Flash 里。

如果在调试器里打开反汇编，你会发现所有函数地址都在0x08000000范围内。这不仅省了 RAM，还意味着你不需要在启动流程里做“代码从 NAND 拷贝到 RAM”这种步骤——那是大容量 Linux 系统才需要操心的事。G031 这种小 MCU 的启动流程之所以看起来短，就是因为省掉了代码搬运环节。

这里也有一个常见的误解：有人以为把一段常驻函数放进 RAM 里执行会更快。对于 M0+ 来说，Flash 读取如果配置了正确的等待周期，XIP 速度已经足够覆盖大多数实时场景。除非你的定时器中断 ISR 对抖动要求高到纳秒级，否则没必要做这种 RAM 执行函数的小技巧。真要做，G031 没有单独的 RAM/Flash 接口仲裁问题，但需要把函数放到指定的 RAM 段并注意链接器脚本，复杂度高、收益低，不建议在应用层用。

3.2 全局变量的本质：每次复位都现场“抄写”一遍初值

从逻辑角度看，全局 = Flash 模板 + RAM 空间 + 拷贝动作。每次上电，RAM 里的变量区都可能是未知的，所以启动代码必须再从 Flash 里把初值模板搬到 RAM，这个过程发生在每一次冷启动或热复位中，不是“只在第一次上电时执行”。所以，任何在 main 之前修改过的全局变量，在复位后都会被初值覆盖回默认值。

这一点在低功耗唤醒场景中尤其需要注意。G031 从 Standby 模式唤醒时，内核会走完整复位流程，所有全局变量会重新从 Flash 加载初值；但如果从 Stop 模式唤醒，程序是继续执行而不是复位，RAM 数据保持不变。我做过一个项目，在 Stop 模式唤醒后还想保留一个计数变量，后来发现唤醒路径不同，行为完全不一样。这也解释了为什么 Stop 唤醒后的外设配置会丢：GPT 什么的寄存器配置是 ROM 代码在启动时写到外设寄存器空间里，但唤醒后外设寄存器实际上保持着原来的值。真正“丢”的是你对某些时钟控制位的依赖，因为外设在停机期间的电源域和时钟可能被关闭。

3.3 const 变量与字面量池：ROM 里的数据如何被 CPU 访问

在 C 代码里访问一个非 const 全局变量，编译出的指令通常是LDR从 RAM 地址加载；访问const变量，则是LDR从 Flash 地址加载。CPU 并不会关心加载的数据来自 ROM 还是 RAM，只要地址映射合法就行。

但要注意写操作的后果。如果代码尝试写一个const变量（比如通过强制类型转换去掉 const 限定），在 Cortex-M 内核上会产生总线错误，进入 HardFault。G031 也不例外。调试时遇到 HardFault，先想想是不是有代码往 Flash 映射地址写了数据。这类问题在启动过程排查时经常遇到：有人把只读数据段的地址当变量缓冲区用，结果启动早期一写入就死机。

还有一点：Flash 中有一块字面量池区域，专门存放立即数。比如LDR r0, =0x40021000这种伪指令，不会被编码进指令本身，而是存放到离代码不远只读区域，再通过一条LDR r0, [pc, #offset]访问。字面量池加大了 ROM 的使用，但这也是为什么代码能高效访问大常量地址——不需要拆成几条 MOV 拼接。

3.4 用 Map 文件核对 ROM 与 RAM 的真实占用

G031 这类小容量 MCU 上，ROM 和 RAM 的预算要精确到字节。实际做法是在编译后打开.map文件，看各段的 Summary。一个典型的 map 输出会在末尾列出类似的表格：

如果发现 .data 段大得异常，往往意味着代码里存在一个巨大的全局数组，且带初始值。如果只有一个很小的uint8_t flag = 0;，.data 段却显示几百字节，就要检查是否有某个静态结构体被隐式初始化成非零值。总而言之，编译产物的大小布局完全由链接脚本串联 ROM 和 RAM，启动代码才能在正确的时间把控制权交到 main 手里。

4. 反汇编视角：逐条指令观察 G031 启动的流水账

4.1 生成反汇编文件的方法

调试启动流程，最好的方式不是看 C 代码，而是看反汇编。GNU 工具链下，一条命令即可：

arm-none-eabi-objdump -d build/app.elf > app.dis

生成的反汇编文件里，每个符号的地址、指令编码、汇编助记符都一清二楚。配合 map 文件，你能把“链接脚本符号地址”和“实际指令地址”对应起来。如果你用的是调试器，也可以在 IDE 里直接打开 disassembly 窗口，从复位处单步看。

4.2 Reset_Handler 首几条指令的解读

下面是我从一个 G031 工程的反汇编中截取并简化的开头片段（实际指令序列因工具链和启动文件版本稍有差异）：

08000000 <g_pfnVectors>: 8000000: 20002000 .word 0x20002000 8000004: 08000145 .word 0x08000145

第一项0x20002000是栈顶地址（RAM 末尾），第二项0x08000145是 Reset_Handler 地址的 Thumb 表示。注意这个值的最低位是 1——Thumb 模式下地址必须保持奇对齐。处理器跳转时实际执行地址是0x08000144。

在 Reset_Handler 的入口处，反汇编通常长这样：

08000144 <Reset_Handler>: 8000144: ldr r0, [pc, #offset] ; 加载 _estack 8000146: mov sp, r0 8000148: bl 0x8000XXX ; 跳转 SystemInit 800014c: ldr r0, [pc, #offset] ; 加载 __data_start__ 8000150: ldr r1, [pc, #offset] ; 加载 __data_end__ 8000154: ldr r2, [pc, #offset] ; 加载 __data_init 8000158: b 0x8000160 ; 进入拷贝循环

逐条翻译：第一条 SP 设置就是栈初始化；然后用 BL 调用 SystemInit 配置时钟；之后用三条 LDR 准备数据段的起始、结束和初值来源地址，进入搬移循环。

看到这里就明白“启动流程中 ROM 如何驱动 RAM”：所有指令都在 ROM 中执行，寄存器保存地址值，指令对二级流水线做连续搬运。每一步操作都指向 RAM 的某个区域，但真正的劳动主体是 CPU 本身。

4.3 数据拷贝循环在指令层面长什么样

反汇编中拷贝循环通常会展开为类似这样：

8000160: ldr r3, [r2], #4 8000164: str r3, [r0], #4 8000168: cmp r0, r1 800016c: blt 0x8000160 8000170: ldr r0, [pc, #offset] ; 加载 __bss_start__ 8000174: ldr r1, [pc, #offset] ; 加载 __bss_end__ 8000178: mov r2, #0 800017c: str r2, [r0], #4 8000180: cmp r0, r1 8000184: blt 0x800017c

我见过新手把mov r2, #0误改成mov r2, #1来“让某个内存区域默认变成非零”，烧录后 ST-Link 反复验证，发现 RAM 里的确有值，但程序一运行就被覆盖。因为这本质是 BSS 清零循环，不是“给初值”的循环。要精确控制某个地址的启动默认值，正确做法是把它放进 .data 段并赋初值。

这里也解释了一个问题：为什么启动阶段不用memset。因为memset是 C 库函数，调用它时链接器可能依赖全局状态，出现循环依赖。启动文件用原始 LDR/STR 指令手写循环，干净利落，不依赖任何外部初始化。如果你用memcpy实现数据搬移，在 CRT 初始化链还没建立完整时，风险会大大增加。

4.4 如何从反汇编判断“启动是否完成”

调试器最容易操作的判断点是：PC 是否到达 main 函数入口。如果 PC 停在0x0800016c和0x8000184附近转圈，通常意味着地址比较条件不满足，也就是拷贝/清零的长度计算错误。原因可能是链接脚本中__data_end__符号被错误放置，或者 RAM 区域大小定义与实际不符。

还可以看栈指针的变化。如果复位后 SP 从一个合理值（比如0x20002000）开始，随着 BL 指令调用 SystemInit，SP 会往低地址移动。每一次压栈对应一次函数调用，每次弹栈 SP 恢复。如果发现 SP 在启动阶段剧烈跳动或跳到非 RAM 范围，十有八九是栈顶设置有问题，或者启动代码在调用 C 库函数时使用了超过栈大小的栈帧。用定时器中断这种深递归场景最容易复现。

5. 启动异常排查：遇到“跑飞”和“死在启动里”怎么下手

5.1 复位后 PC 立刻进入 HardFault，先查什么

启动阶段 HardFault 是嵌入式开发者最不想看到的现象之一，但也是最能说明问题的。首先要分清楚：是“从复位开始就 HardFault”还是“执行到某个函数才 HardFault”。两者排查路径完全不同。

如果单步从复位开始，第一步就跳进了 HardFault_Handler，大概率是向量表本身的问题。检查三件事：一是向量表第一项 SP 是否为合法 RAM 地址；二是第二项 Reset_Handler 地址最低位是否为 1（Thumb 位）；三是链接脚本把.isr_vector段是否正确放到了0x08000000。如果某个向量为 0，或地址不可执行，CPU 在取指时就会触发不可屏蔽的故障。

如果是执行了一段时间才 HardFault，更可能是外设寄存器写错、Flash 等待状态不对、或者代码访问了非法地址。启动阶段访问非法地址的常见操作是：往只读地址写入、解引用空指针、访问未使能时钟的外设寄存器。G031 上外设寄存器如果不先打开对应的 RCC 时钟门，访问会直接导致总线错误。

5.2 三个高频大坑：链接脚本覆盖、局部大数组、Flash 等待状态

第一个坑：链接脚本 FLASH 长度定义误。比如芯片实际 Flash 是 32KB，链接脚本却写成 64KB，编译时某个段被安排到超出物理 Flash 的位置——链接器未必报错，但烧录后启动流程会从那片不存在的地址取指，结果是复位即跑飞。遇到这类问题，检查工程里用的具体芯片型号，和链接脚本里的 ORIGIN/LENGTH 是否一致。

第二个坑：局部大数组导致栈溢出。G031 SRAM 只有几 KB，有一个陷阱特别典型：uint8_t buf[2048];作为局部变量声明在函数里，如果函数被调用时主栈还没建立完全，或者栈大小只有 1KB，一次入栈就可能把 .data/.bss 区域踩烂。踩烂的后果可能是某个全局变量被覆盖，而全局变量的值影响启动分支，形成难以理解的逻辑错误。这个坑的排查方法是用调试器查 SP 的变化区间，看是否触底。

第三个坑：Flash 等待状态配置延迟。这个问题在启动阶段不明显，因为上电默认使用 HSI16 且 Flash 等待周期为 0，代码能跑。但如果 SystemInit 切换 PLL 到 64MHz，等待周期没有同步增加，Flash 读取时序就不够，表现为随机取指错误，PC 跳到一个奇怪的 Flash 地址。这个坑几乎只能靠“查 SystemInit 配置 + 核对 Flash 等待状态”解决，没有捷径。

5.3 用调试器快速复现排查链路

我的习惯步骤是：

1. 复位后先停住，看寄存器窗口：SP 是否为 RAM 区合法地址，PC 是否为 Reset_Handler 的 Thumb 地址。
2. 打开反汇编窗口，从 Reset_Handler 单步。每步都盯着 SP 和 PC，注意 BL 跳转后 SP 有没有正常回退。
3. 在数据拷贝循环的起始和结束处各下一个断点。比较__data_start__到__data_end__之间是否填满预期值。
4. 跳到 main 入口后，先在内存窗口检查 BSS 段区域是否全部为 0。如果不是，说明清零路径有问题。
5. 最后把 Flash 等待状态的寄存器值读出来，确认和当前 HCLK 是否匹配。

这套流程看着简单，但只要坚持走一遍，90% 的启动异常都能定位。最怕的是跳过单步、直接全速运行却发现死机，然后开始怀疑编译器、怀疑链接器、怀疑人生——其实问题往往就在这几个基础环节。

6. 在 G031 上值得单独说的几个启动特性

6.1 为什么 G031 的启动“看起来很快”

很多从 Cortex-M3/M4 转过来的开发者会发现，G031 的启动流程比较轻快。一方面是因为 M0+ 内核功能精简——没有 FPU、没有 MPU，SystemInit 里不需要做协处理器使能、MPU 配置；另一方面是 G031 的 Flash 容量小，启动阶段需要搬移的数据段和清零的 BSS 段都很短。

但“启动快”不代表你可以不看启动流程。恰恰因为启动路径短，任何一点时序错误都会被放大。比如 HSI16 转 PLL 时，如果 PLL 锁定超时，要么死等，要么跳过切换继续用 HSI。有些库代码里用了超时等待，调试时如果发现时钟没上去，先检查 PLL 配置的输入频率和倍频系数是否允许。

6.2 没有 VTOR 的中断向量重定位问题

Cortex-M0+ 没有 VTOR 寄存器，这意味着向量表的地址是固定的——永远从0x00000000映射区开始。如果你要写一个 BootLoader，把 App 放在 Flash 后半段，并且希望 App 的中断能正常工作，就必须面对这个问题。

常见方案是：BootLoader 校验完固件后，把 App 的向量表复制一份到 RAM 或保留在 Flash 前半段，然后关闭所有中断、跳转到 App。由于向量表地址无法重映射，App 的中断向量实际上还留在原来的位置，因此你必须保证 BootLoader 驻留区（向量表所在区）不因 App 更新而被篡改，或者让 App 的中断处理全部通过间接跳转绕开中断向量表。这在实际项目中很麻烦，也是很多人从 M3/M4 转到 M0+ 后不适应的地方。

有一个相对实用的妥协方案：App 不依赖任何中断，完全用查询方式驱动。这样即使向量表没有重定位，App 也能正常运行。我见过某个模拟项目就是这么干的——BootLoader 在主 Flash 前 8KB，App 跑在 8KB 之后，App 里所有外设都用轮询，中断只保留系统滴答定时器（通过 BootLoader 的变量跳转处理）。虽然不是最优雅，但在小容量 MCU 上足够可靠。

6.3 Standby 唤醒和 Stop 唤醒后的启动路径差异

G031 的低功耗模式对启动流程的影响经常被忽略。从 Standby 唤醒相当于一次完整复位，所有 RAM 数据都会丢失，整个启动流程重新走一遍，全局变量从 Flash 重新抄写。从 Stop 模式唤醒则是“继续执行”，不经过复位流程，RAM 内容保留，外设寄存器状态视配置而定。

如果程序里依赖某个“唤醒后继续”的标志，正确的保存位置不是 RAM 全局变量（因为 Standby 会清 RAM），而是要放到备份寄存器（如果 G031 有）或者 Flash 的特定区域。我调试低功耗设备时，一开始把唤醒标志放在 RAM，结果 Stop 唤醒正常，Standby 唤醒数据清零，导致行为不一致。后来才明白，不同唤醒路径对应的是“复位”和“非复位”两种截然不同的状态机。

6.4 启动期间的 GPIO 状态：别等到 main 才做初始化

上电复位后，G031 的 GPIO 默认是模拟输入模式（具体取决于复位配置）。从复位到 main 之间，这段“无主状态”时间很短，但如果你在启动代码里调用了 SystemInit、数据搬移等步骤后，GPIO 才被应用代码初始化，那么在此之前引脚可能呈现高阻或不确定状态。某些外围电路——比如驱动 MOSFET 的推挽引脚、蜂鸣器、继电器——如果在这个窗口被浮空电平误触发，会造成短暂抖动。

应对方法有两种：一是用硬件上拉/下拉电阻保证复位期间的电平安全；二是在 SystemInit 之后、数据搬移循环完成之前，尽早放置一小段 GPIO 初始化代码，让关键引脚先进入确定状态。后一种做法需要修改启动文件或板级初始化流程，不太适合对启动文件不熟的开发者直接上手。更稳妥的做法是在 main 最开始的位置立刻配置关键引脚，并保证让链接器和硬件设计都尽量避免复位瞬间的异常动作。我这些年做 G031 项目，无论需求多急，都会先在原理图上把复位期间的引脚电平逐路确认一遍。

再分享一点经验：在启动流程上花费的时间，换来的是整个项目的稳定性。真正摸透 G031 的启动过程和 ROM/RAM 协作后，你再遇到“程序能跑但行为诡异”的问题，会先去看复位后的寄存器状态、检查 BSS 清零、核对时钟和 Flash 等待周期，而不是一上来就埋头找代码逻辑错误。这颗芯片的内部逻辑并不复杂，难点在于“要多想一步”——想一想你的 C 代码在启动汇编面前，到底是如何从 ROM 里的模板一步步变成 RAM 里的实在状态的。养成每次编译后看一眼 map 文件的习惯，再高级的调试技巧，都不如你对自己二进制文件的理解来得可靠。