先说个真实场景：群里有人发来截图，Keil 下载界面里 Flash 起始地址是0x08000000，下午他切到 ESP32 用 esptool 烧录，命令行里写的是0x10000，晚上又刷了一个 ESP8266 的旧固件，教程里让他填0x6000。他直接懵了，问我这三个地址到底谁是对的，为什么同一个“烧录地址”一会儿一个样。
我告诉他，这三个值都对，只是它们属于三套完全不同的地址体系。这个问题的核心不是“哪个地址正确”，而是“你正在用谁的眼睛看这块芯片”。如果你也被这种地址跳来跳去搞到头大，这篇文章值得你花十分钟读完。我会把0x08000000、0、0x6000这三类常见值背后的原理拆开讲清楚，再送你一套判断地址类型的排查思路，最后附上查看 ESP32 烧录地址的几条实操路径。
1. 烧录地址是个“视角”问题：绝对地址、映射地址、文件偏移三件事
先说结论：烧录时填写的地址，本质上取决于“谁在看地址”。同一颗芯片，CPU 看到的内存地址、烧录工具操作的 Flash 偏移、固件文件里记录的地址，往往是三个不同的数字。
1.1 三个地址各自说明白
第一类叫绝对地址，也叫总线地址。这是 CPU 通过地址总线访问存储器的地址，程序员写链接脚本、看 map 文件、用调试器设断点时接触的就是它。比如 STM32F103 的片内 Flash 起始地址是0x08000000，SRAM 起始地址是0x20000000，这两个值写在芯片参考手册的“Memory Map”章节里，改不了。
第二类叫映射地址。很多芯片为了启动方便，会把物理上的 Flash 再“投影”到另一个地址区间。典型的例子是 Cortex-M 内核复位后从0x00000000取栈顶指针和复位向量，但 STM32 的 Flash 物理首地址却在0x08000000，芯片内部的 boot ROM 会在复位期间把0x08000000这一段空间重映射到0x00000000，让 CPU 能顺利启动。也就是说，同一个物理 Flash 单元，通过两个地址都能访问到。
第三类叫文件偏移，也叫物理偏移。它针对的是二进制文件里的数据位置。BIN 文件没有地址信息，就是一个纯数据流，烧录时工具需要你告诉它“这段数据塞到 Flash 开头的第几个字节”，这个偏移从0开始计数。HEX 文件则自带地址，不用你操心，但它里面记录的也是目标地址，不是偏移。
这三类地址之间的换算关系很直接：绝对地址 = 芯片的 Flash 基址 + 文件偏移。比如 STM32 的 Flash 基址是0x08000000，如果你想让程序跑在 Flash 偏移0x10000处，链接脚本里要写0x08010000，烧录工具把 BIN 文件放到偏移0x10000的位置，这两个动作描述的是同一件事，只是视角不同。
1.2 用一张表收拢常见的“变来变去”的值
| 你看到的地址 | 它大概率是什么 | 常见出现在哪 |
|---|---|---|
0x08000000 | Cortex-M 芯片的 Flash 绝对基址 | STM32、GD32 等基于 ARM Cortex-M 内核的单片机；Keil、J-Flash、STM32CubeProgrammer 的默认下载地址 |
0x00000000 | Flash 物理基址为 0 的芯片，或文件偏移起点，或工具省略基址后的显示 | NXP LPC8xx、赛普拉斯 PSoC4、部分国产 M0 芯片；SPI Nor Flash 离线烧录；OpenOCD 的flash write_image命令 |
0x10000 | ESP32 默认出厂分区表里 app 分区的 Flash 偏移 | esptool 烧录 ESP32 应用固件时 |
0x8000 | ESP32 分区表的 Flash 偏移 | esptool 烧录 partition-table.bin 时 |
0x6000 | Flash 物理偏移，可能是自定义分区、文件系统区、老 SDK 的某个镜像段的写入起点 | 某些 ESP8266 教程、部分厂商 SDK 的烧录脚本、SPI Flash 文件系统分区表 |
记住这张表后，再看到任何奇怪的地址，第一反应不应该是“这地址对不对”，而是“这个地址是哪个视角的数字”。搞清楚这一点，后面所有问题都迎刃而解。
2. 0x08000000 不是写出来好看的：Cortex-M 内核的启动与 Flash 基址
0x08000000是 ARM Cortex-M 架构里非常经典的一个地址，经典到很多人已经不再问它为什么是这个值。但它背后的逻辑值得展开，因为搞懂它，你就搞懂了 STM32 为什么“烧录地址写成 0x08000000”，也搞懂了为什么有些芯片偏偏不用它。
2.1 为什么 Cortex-M 固定从 0x00000000 起步，却把 Flash 放在 0x08000000
ARM Cortex-M 内核在硬件设计上规定，复位后处理器从0x00000000读取初始栈顶指针（MSP），从0x00000004读取复位向量。这是内核层面的硬编码，任何 Cortex-M 芯片都得遵守。但 ARM 并没有规定片内 Flash 必须放在0x00000000，于是芯片厂商在设计内存映射时有了两种路线。
路线 A 是把 Flash 物理地址直接放在0x00000000，LPC8xx、PSoC4 这些芯片就是这么干的，它们的 Flash 基址就是从 0 开始，烧录地址自然就显示0。好处是省事，坏处是整个内存空间的最低地址段被 Flash 占用，调试接口、系统配置区的位置要往后挪。
路线 B 是 STM32 的做法：把 Flash 放在0x08000000，SRAM 放在0x20000000，然后通过 boot ROM 在复位期间做一个别名映射，让 CPU 从0x00000000取向量表时实际访问到0x08000000的内容。这个映射不是把 Flash 内容“复制”过去，而是地址解码层面的一根“虚拟导线”，同一片物理存储同时在两个地址空间可见。
为什么选0x08000000而不是0x00000000？因为这样可以把整个低地址区留给中断向量、系统存储器（System Memory，也就是出厂 ISP 引导程序）、选项字节等一堆系统资源，Flash 在地址空间里有一个清晰、独立、不会和系统区冲突的“大块头”位置。逻辑上，你可以把0x08000000理解成一个公寓楼的单元号，0x00000000是前台，前台登记表上写着“1 单元 801 室”，CPU 按登记表去找人。
2.2 SWD/JTAG 烧录时工具看到的地址
当你用 ST-Link、J-Link 通过 SWD 或 JTAG 接口给 STM32 烧录时，调试器走的是芯片内部的调试访问接口（DAP），它访问的是总线地址空间的原始地址。所以 Keil 的 Flash Download 界面里会显示0x08000000，STM32CubeProgrammer 的地址栏默认也是0x08000000，J-Flash 里选择好设备型号后，Flash 基址同样自动填成0x08000000。这不是烧录工具自作聪明，而是芯片的调试数据库（FLM 文件、设备描述文件）里明确记录了 Flash 的总线地址。
这里有个常见的困惑：既然 CPU 复位后从0x00000000启动，为什么调试器不直接写0x00000000？答案是 CPU 的启动别名和调试器的访问地址不一定完全一致。调试器在烧录时通常不会依赖这个别名映射，而是直接操作 Flash 控制器的寄存器，按总线地址0x08000000来擦除和写入。烧录完成后，复位时内核自然通过 boot ROM 的别名映射从0x00000000启动到 Flash 里的程序。所以你在调试界面里看到0x08000000是正常的，看到某些国产 M0 芯片直接显示0，也别觉得奇怪，那只是芯片选了路线 A。
2.3 链接脚本里的 FLASH ORIGIN 和实际烧录地址的关系
STM32 工程的链接脚本（GCC 用.ld文件，Keil 用.sct文件，IAR 用.icf文件）里会有一段类似这样的定义：
MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K }ORIGIN = 0x08000000决定了编译出的代码里每条指令、每个全局变量的运行地址。如果你把 ORIGIN 改成0x08010000，编译出的 HEX 文件里第一条启动代码的地址就会变成0x08010000。此时如果用调试器直接下载，程序照样能写进 Flash，但复位后 CPU 会去0x08000000找向量表——那里如果没有东西，程序直接跑飞。这就是为什么 Bootloader + App 架构里，App 的链接地址必须和烧录位置匹配，且 App 必须在启动早期把向量表偏移寄存器（VTOR）改到0x08010000。
在这个架构下，同一个 App 工程里会出现三个数字：链接脚本里的0x08010000（运行地址）、HEX 文件里每条记录的地址（目标地址）、Bootloader 接收 BIN 时上位机填写的0x10000（相对于 Flash 基址的偏移）。数字不同，但描述的是同一个物理位置。搞不清这一点，IAP 升级时最容易出“烧进去了但跑不起来”的诡异故障。
3. 什么时候会看到 0？从向量表重映射到“从头开始数”
如果说0x08000000是 STM32 的专属名片，那0就是一个通用得不能再通用的地址，看到它时你得格外小心，因为它背后至少有四种可能，每种对应的操作完全不一样。
3.1 有些芯片的 Flash 基址本来就是 0
我在前面已经提到了路线 A：Flash 物理地址就在0x00000000。这类芯片在 Cortex-M 生态里数量不少，尤其是一些低成本、低引脚数的 M0/M0+ 芯片。你用 Keil 或者 IAR 新建工程时，如果选择的设备是这一类，下载算法里的 Flash 起始地址就会自动填0。此时你把程序烧到0，它就能正常启动，因为 CPU 复位后本来就要从0x00000000取值，Flash 正好就在那里，连别名映射都省了。
判断方法很简单：打开芯片参考手册的 Memory Map 章节，看 Flash 的起始地址是多少。如果是0x00000000，那你以后所有“Flash 基址”相关的计算，起点都从 0 开始，非常省心。如果是0x08000000这种非零值，你就得时刻记得加基址。
3.2 外部 Flash、文件系统、OTA 升级包：从偏移 0 讲起
第二种“看到 0”的场景和 MCU 内核无关，而是操作对象本身没有基址概念。比如一颗 W25Q128 SPI Nor Flash，容量 16MB，它内部只有一个从0x0000000到0xFFFFFF的线性地址空间，没有“映射到 CPU 的哪个总线地址”这种事。你把 Flash 芯片拆下来放到编程器座子上离线烧录，或者用 SPI 读写器直接操作时，地址就是从 0 开始数的。这时你写0，意思就是“从 Flash 芯片的第一个字节开始”，非常直观。
类似的，OTA 升级里经常提到的“分区偏移”“镜像偏移”，本质上也是从 Flash 开头开始算的。比如 ESP8266 的某个 OTA 方案里，固件升级包里的user2.bin被要求写到 Flash 偏移0x81000，这个值不是说程序运行地址是0x81000，而是说这个文件的数据在 Flash 里的存放位置。ESP8266 在启动时会通过 bootloader 把对应偏移的内容加载到内存映射区去执行。你把“Flash 偏移”和“运行地址”混为一谈，后面会吃大亏。
3.3 工具“显示 0”其实是把基址省了
第三种情况比较坑，坑在工具层面。某些烧录工具为了让用户操作简单，地址栏里显示的不是目标地址，而是“相对当前选中设备 Flash 基址的偏移”。你选好单片机型号后，工具已经知道 Flash 基址是0x08000000，于是地址栏默认填0，意思是“从 Flash 开头写入”。此时你如果自己手动改成0x08000000，反而可能出问题，因为工具会在这个偏移的基础上再加一次基址，结果变成0x100000000，直接溢出。
还有个非常常见的例子是 OpenOCD 的flash write_image命令。它的第一个地址参数在很多用法里表示的是镜像文件内部的偏移，而不是目标 CPU 地址。比如flash write_image erase app.bin 0这一步里的0表示“从 app.bin 的文件开头开始读”，实际写入位置由 OpenOCD 根据当前配置的目标 Flash 来自动决定。如果你不理解这个设计，看到命令里写着 0 就去搜“STM32 烧录地址为什么是 0”，大概率会被老手反问一句“你这是在烧 BIN 还是烧 HEX”。
3.4 Bootloader 跳转与向量表重映射里的“0 地址”
最后一种看到 0 的场景出现在程序运行期。Cortex-M 内核无论怎么跳转，中断向量表始终要在0x00000000附近取向量，除非你显式改了 VTOR 寄存器。于是很多带 Bootloader 的工程里，Bootloader 的向量表在0x08000000，App 在启动时要把 VTOR 设为0x08010000，但在跳转瞬间、或者 App 还没来得及修改 VTOR 时，如果发生任何中断，内核会尝试从0x00000000取向量——那里此时映射的是 Bootloader 的向量表，所以一个由 Bootloader 启动的 App，在刚跳过去那一刻其实处在“逻辑地址 0”的控制之下。这也是为什么很多人调试 App 时发现“复位后进不了 main”，因为 App 的向量表没有搬到正确的位置。
明白这些之后，你再看到“为什么烧录地址有时是 0”这个问题，应该能意识到：这不是一个标准答案的问题，而是一个需要按场景分类的问题。下面我来讲第三个值0x6000，它的性质也藏在“偏移”这两个字里。
4. 0x6000 和 0x10000 这些值：ESP 系芯片的 Flash 偏移地址体系
0x6000这个地址值，如果你玩 ESP8266/ESP32，应该经常在各类教程的烧录命令或烧录工具地址栏里见到。但它和 STM32 的0x08000000完全是两套话语体系。要彻底理解它，得先接受一个事实：ESP 系芯片很少让你直接和 CPU 总线地址打交道，烧录工具给的都是 Flash 偏移。
4.1 ESP8266/ESP32 的地址观：内存映射地址和 Flash 偏移是两套规则
ESP8266 和 ESP32 的片内 Flash 是通过 SPI 接口外接的（ESP32 部分型号甚至把 Flash 封装在模组里）。CPU 访问 Flash 里的代码时，不是直接发出一个0x08000000这样的地址去读，而是通过芯片内部的指令缓存/数据缓存把 Flash 的一段内容映射到高位地址空间。
以 ESP32 为例，外部 Flash 被映射到多个窗口，比如指令总线窗口在0x400D0000附近，数据总线窗口在0x3F400000附近。你如果去读 map 文件，会看到函数地址长这样：0x400D1234，这个值就是程序运行时代码在内存映射区的实际地址。但你用 esptool 烧录时，工具根本不关心这个高位地址，它关心的是文件数据要写到 SPI Flash 物理空间的哪个偏移。bootloader 启动时会从 Flash 偏移处把内容读出来，加载到对应的内存映射窗口，程序才能跑起来。
所以 ESP 系的烧录地址，几乎全部是小而美的偏移值：0x1000、0x8000、0x10000、0x9000……这些不是 CPU 运行地址，它们是 Flash 内部的物理偏移。0x6000也是这一类。
4.2 常见分区表和烧录偏移速查
我在实际项目中整理的常用烧录偏移如下，不同 SDK 版本可能有差异，但整体结构稳定：
| 芯片 | 烧录内容 | 典型 Flash 偏移 |
|---|---|---|
| ESP8266 | bootloader（使用 NONOS SDK + boot 时） | 0x00000 |
| ESP8266 | user1.bin（单 OTA 应用） | 0x01000（部分老版本为0x02000或0x6000，以官方脚本为准） |
| ESP8266 | esp_init_data_default.bin（RF 初始化数据） | 0xFC000（1MB Flash） |
| ESP8266 | blank.bin（清空系统参数区） | 0xFE000（1MB Flash） |
| ESP32 | bootloader.bin | 0x1000 |
| ESP32 | partition-table.bin | 0x8000 |
| ESP32 | app.bin（出厂单分区） | 0x10000 |
| ESP32 | 双 OTA 分区 ota_0 / ota_1 | 0x110000/0x210000（取决于分区表） |
回到0x6000这个问题上。它不是 ESP32 默认出厂布局里的标准分区起点，但它作为“Flash 偏移”的典型值，经常出现在几类场景里：某些厂商 SDK 里自定的 app 写入起点、文件系统分区的偏移、或者老版本 ESP8266 教程里某个镜像段的烧录地址。甚至有些教程把0x60000抄成了0x6000，这种笔误也会让你在群里看到各种奇怪的填法。
我给你的建议很简单：看到0x6000这种以0x开头的小数值，先默认它是 Flash 偏移，不要去对 CPU 执行地址。如果你不确定它属于哪类偏移，去找官方烧录脚本和编译输出文件（.map、.partition），脚本里写的地址就是最可信的答案。
4.3 实操：怎么看 ESP32 的烧录地址
“怎么看 esp32 的烧录地址”这个需求，我建议你掌握三条路径，按需选用。
第一条路径，看编译产物。ESP-IDF 工程编译完成后，终端会打印类似这样的信息：
App "app" is the default app, at 0x10000 Partition table: nvs : offset 0x9000, length 0x6000 otadata : offset 0xf000, length 0x2000 phy_init : offset 0x11000, length 0x1000 factory : offset 0x10000, length 0x100000这里的offset就是烧录地址，直接照着填就行。
第二条路径，看分区表文件。ESP-IDF 工程根目录下的partitions.csv里每一行的第二列就是偏移：
# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x100000,如果你用的是 Arduino IDE 的 ESP32 支持包，也可以在菜单“Tools”里的 Partition Scheme 看到几种预设布局，每个布局里 app 的起始地址会显示在编译输出日志里，比如Chip is ESP32-D0WD-V3、App binary at 0x10000之类。
第三条路径，用命令反查。已经烧录到芯片里的固件，可以用 esptool 查分区的实际信息。比如：
esptool.py --port COMx read_flash 0x8000 0x1000 partition_table.bin esptool.py image_info build/your_app.binread_flash把分区表区域读出来，image_info直接解析 app.bin 的头部，能看到它面向哪个分区、建议烧到哪个偏移。另外还有一个更直接的命令esptool.py --port COMx merge_bin，它会把多个 bin 合并成一个整片镜像，输出的地址列表能帮你整体核对烧录规划。
我个人最常用的是“先看partitions.csv，再对编译日志”的组合拳，因为整个地址体系的源头就是分区表，只要分区表没改，烧录偏移就稳定。
5. 工具和文件格式也会“骗人”：HEX、BIN、下载算法与默认地址
在嵌入式开发里，很多“烧录地址对不上”的纠纷，根源不在芯片，而在文件格式和工具默认行为。这两个东西最容易让新手产生“为什么变来变去”的错觉。
5.1 HEX 自带地址，BIN 全靠你填
Intel HEX 文件是一种文本格式，每一行都带有地址信息。比如 Keil 导出的 hex 文件里经常能看到这样的记录：
:020000040800F2 :10000000F0C24F0000A04F0000D04F0000第一行的04类型是“扩展线性地址”，意思是接下来的数据地址要高 16 位前缀，0800就代表0x08000000这个段。所以 HEX 文件自带了“要把数据放到哪里”的信息，烧录工具读入 HEX 后，不需要你填地址，它自己知道。
BIN 文件则完全不同。它就是一段裸数据，内部没有任何地址信息。你把一个 BIN 给烧录工具，它只能问你要“放到哪个地址”，你填0x08000000和填0x00000000，对工具来说就是把同一段数据放到了不同的位置。**如果填错，工具大概率不会报错，它只会忠实地写错。**这也是为什么我给所有做量产工具的朋友一个建议：BIN 文件必须配套记录烧录地址，文件名里都带上，别偷懒。
5.2 烧录工具里的“默认地址”可能来自芯片数据库
Keil、STM32CubeProgrammer、J-Flash 这类工具会为每种芯片维护一个描述文件，里面记录了 Flash 的基址、大小、编程算法等。你选择设备型号后，工具自动把 Flash 基址填进地址栏，这个值对你来说是透明的。
但有些工具默认显示0，并不代表芯片 Flash 基址是 0，而是工具的地址栏定位是“相对偏移”，或者设备描述文件没有正确加载。遇到这种情况，我的排查顺序是：先看工具左下角状态栏有没有正确识别芯片型号，再进入设置里看 Flash 编程算法（FLM/FlashLoader）是否匹配，最后参考芯片手册确认 Flash 基址，手工填一次试试。
5.3 服务烧录和产测时经常踩的坑：地址填错但不报错
量产烧录场景里，“地址填错但不报错”是最可怕的坑，因为产品可能在生产线上大量流出，直到终端用户升级时才集体暴露。我见过一个案例：某工控板用 STM32F407，IAP 上位机接收 BIN 时，开发人员把写入地址写成了0x08000000，但 BIN 文件本身是从 App 的偏移 0 开始的，也就是说它本来应该写到0x08010000。上位机没做校验，生产线烧录了 200 块板子，全部能开机，因为 Bootloader 还在，但一进 App 就死机。
正确的做法很简单：**IAP 上位机里的地址，要么直接填 Flash 内部的物理偏移（如0x10000），由 Bootloader 把它加到基址上；要么填绝对地址（如0x08010000），由上位机把它减去基址后计算偏移。但绝对不要两边各加一次。**我在项目里都会强制上位机在写第一个扇区前回读校验，并对文件名里的起始地址做合法性判断，一旦发现地址落在 Bootloader 区域直接拒绝烧录。
6. 遇到“奇怪烧录地址”时的排查思路
到这里，你应该已经掌握了三种地址体系的底层逻辑。最后这套排查思路，是我这些年处理过的“地址怪问题”的总结，按这个顺序走，大多数情况下五分钟内能定位问题。
6.1 先回答三个问题
接到一个“烧录地址不对”的问题时，我先问自己三个问题：
- 我烧的是什么芯片？查它的参考手册 Memory Map，确认 Flash 基址是不是 0，或者是
0x08000000这种非零值。 - 我手里的是什么文件格式？HEX 自带地址，不用我管；BIN 没有地址，我填的数字就是它的目的地址。
- 工具地址栏的标签是 Address 还是 Offset？如果工具界面写的是 Address，填绝对地址；如果写的是 Offset，填相对 Flash 基址的偏移，两者不要混用。
这三个问题问完，90% 的“地址变来变去”问题已经有了答案。
6.2 一条实用的排查链路
如果问题还没解决，我会按下面的链路逐层排查：
- 先看官方烧录脚本。ESP 系列打开
flash_download_tool或 esptool 命令行，STM32 打开 CubeProgrammer 的烧录配置，脚本里写的地址就是项目作者验证过的地址。 - 再看链接脚本和分区表。GCC 的
.ld文件、ESP-IDF 的partitions.csv、Keil 的.sct文件，这些是“程序放在哪里”的源头真相。 - 再看 Bootloader 的跳转目标。很多程序不是从 Flash 开头启动的，Bootloader 跳转的地址才是 App 实际运行的地址，烧录时必须和它匹配。
- 最后做一次回读校验。读回 Flash 内容和 BIN 文件对比，前 16 个字节一致说明地址填对了，不一致就说明填错了，不用猜。
以 ESP32 为例，完整命令大概是：
esptool.py --port COMx read_flash 0x10000 0x1000 readback.bin然后对比readback.bin和你要烧录的app.bin开头若干字节。如果一致，烧录地址百分百没问题。
6.3 这些年踩过的坑，集中盘一下
我不太喜欢讲“教训”，因为教训通常是我自己交过学费换来的，能省一个是一个。
第一个坑：ESP8266 的老固件烧录地址看教程，教程里写0x6000，我直接就填了。结果上电后串口有启动日志但程序不跑，最后翻官方脚本发现那个文件应该烧在0x00000。后来我把教训总结成一句话：教程里的地址，一定要和固件配套；换一个 SDK 版本，烧录偏移可能就变了。
第二个坑：STM32 IAP，上位机地址填了绝对地址0x08010000，但我的 Bootloader 在接收数据时又做了一次偏移处理，数据被写到了0x08020000。那次问题排查了很久，因为板子能启动，App 也能运行，只是偶尔因为 Flash 里旧数据干扰出现随机死机。最后是靠回读校验才定位到是地址重复偏移。
第三个坑：外部 Nor Flash 离线烧录时，我用编程器默认地址0烧录，读出来数据是对的，但焊到板子上系统死活启动不了。后来发现因为板子的 Flash 片选和地址线做了硬件地址偏移，软件要跳过前 4KB 才能访问到烧录的数据。从那以后我拿到任何带外部存储的板子，都会先查硬件原理图确认存储器映射，再决定烧录地址。
最后分享一点实际体验
地址这个问题，理论上不难，难的是每次都要提醒自己“切换视角”。我现在无论用什么工具烧录，都会先瞄一眼地址栏前面的标签：写着 Address 我就填绝对地址，写着 Offset 我就填偏移；拿到 BIN 文件我先问一句这文件带不带地址信息；换了芯片型号我先查一句 Flash 基址是不是 0。这三个习惯帮我挡掉了至少一半的“为什么我烧录失败了”问题。
如果你也经常在 STM32 和 ESP 系列之间来回切换，建议你把各平台的常用烧录偏移整理成自己的速查表，写代码累了就对着它过一遍。等你形成了条件反射，以后再看到0x08000000、0、0x6000，就会像我一样淡定：不是地址变来变去，而是我们看的从来就不是同一个数。
